New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smartmatch signatures #16260
Comments
From zefram@fysh.orgCreated by zefram@fysh.orgEveryone would like to have type constraints in signatures, but a Suppose that the smartmatch/switch discussions lead to a version of Matcher objects can then be used as type metaobjects. In general So a scalar signature item could specify a type constraint by referring use Smart_Type qw(Num Str union HashRef_of); # imaginary module "~" references the smartmatch operator while not being longer than use Smart_Type qw(Str HashRef_of); With respect to the last of those examples, usually the type we want to In optional parameters I imagine the default value expression would be It's a little more difficult to apply type constraints to array and It's also necessary to think about how type constraints would interact Perl Info
|
From @cpansproutOn Mon, 20 Nov 2017 06:59:19 -0800, zefram@fysh.org wrote:
Those would be subs (maybe constants), right?
?: is also immensely useful. Make ?: the lowest precedence permitted.
Or the other way round. So it’s a matter of arguing about the syntax. Finding something that conveys permanence without confusion with other operators is hard. My first thought was = to imply state variable assignment, but then you have ~=, which means something completely different elsewhere. Since the syntax before the ~ is not restricted so much, maybe: sub fronk ($foo state~predicate()) Unambiguous, but confusing! I think the indicator, whatever it is, ought to be before the ~, since putting it after the ~ limits the syntax, unless we start requiring whitespace after the ~. I will trying brainstorming with every symbol of my keyboard: `~ -- confusing
So the only options that I do not find objectionable are: If we want fixed predicates to be the default: *~
If we want dynamic predicates to be the default: ^~
If we go with that last one, we will have people deliberately parenthesizing their predicates, just to make funny faces: sub fronk (@a :~( Str )) {...}
Skipping the constraint would be faster. That would assume the programmer knows what he is doing, which is not an unreasonable assumption.
Don’t indicate it; just document it as the behaviour. People can write array-specific predicates. sub foo (@a
In terms of what the smartmatcher sees, I think the only reasonable behaviour is to do the aliasing first, and then apply the type constraint to the lexical variable created by the parameter. So (\$x~Str) will effectively do (\$_[0] ~~ Str) In the former case, $_[0] would not necessarily be a ref, but in the latter case it would have to be. There is still the question of what order the \ and ~ come: ($x\ The former would be much easier to parse. -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
Yes. All are subs. Num and Str are constant-valued nullary subs,
That's the precedence level immediately above assignment, so that
Think of the Huffman coding: a constant type is the usual case. However,
Not really usable, because it would interact with nameless parameters.
I was thinking more about deliberate use of an out-of-constraint default.
Is it? With \$x type aliasing, it would make just as much sense to With \@x aliasing, we can't apply the smartmatch to @x itself, only
That doesn't make sense. Perhaps you meant "(${$_[0]} ~~ Str)".
Those are the other way round, according to the aliasing rules that
Yeah. "($x~Str\)" seems more logical to me, but it does raise a -zefram |
From @cpansproutOn Mon, 20 Nov 2017 10:03:05 -0800, sprout wrote:
Sigh. If I don’t proofreading my own writing, I end up sounding like Google Translate. -- Father Chrysostomos |
From @cpansproutOn Mon, 20 Nov 2017 10:46:50 -0800, zefram@fysh.org wrote:
Perhaps parse_condexpr().
I think I prefer this idea.
But you already proposed earlier than (@x If we want *some* consistency, then array parameters should always get one level of referencing more than scalar parameters.
Yeah, I wrote it really quickly.
There is a fundamental problem with the way the parsing functions work. Namely, the token that follows the code being parsed must be recognizable by the lexer as being of a particular precedence. This severely limits the usefulness of recursive-descent parsing functions. In an ideal world, parse_fooexpr() would parse as much as possible until it reaches a token that does fit in the ‘foo’ rule in the grammar. (Sorry, I can’t remember offhand the term for that.) I am by no means an experienced yacc user, so I don’t know how you go about this. But I think it would entail changing the way errors are handled in perly.y. Currently sideff is defined in terms of error | .... With strict recursive-descent parsing (not involving any yaks), for each precedence level you have a function that does: if (!parse_lower_precedence()) and it’s pretty straightforward. I don’t know whether perl could switch to something like that, though, because of do{BEGIN...} etc. Fixing this, however, would open up the parsing possibilities without adding more special cases to the lexer for the tokens we need to end on. -- Father Chrysostomos |
From @LeontOn Mon, Nov 20, 2017 at 3:59 PM, Zefram <perlbug-followup@perl.org> wrote:
I don't really see the point of discussing this now, when we're probably Leon |
Migrated from rt.perl.org#132473 (status was 'open')
Searchable as RT132473$
The text was updated successfully, but these errors were encountered: