-
Notifications
You must be signed in to change notification settings - Fork 15
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
Implement +=, *= and all the other assignment operators #152
Comments
The cool thing is that
This also falls out of |
If we go ahead and make assignment a statement form, I guess this one becomes a statement form too. |
Even here, lvalues get involved in a big way. Any side effect happening in the path of the lhs should happen once, which relates both to the Single Evaluation Rule and to the Assignment Protocol. |
I think this is wrong, but without observable consequences, so to speak.
New attempt at implementation:
|
Heh. The new implementation is left-recursive. Not a showstopper in itself, of course, but... interesting.
|
It's possible |
That brings up another point. The "chaining operators" in Perl 6 (corresponding to all the comparison ops in 007) are "too diffy" to be assignmentopified. Perl 6 has a precedence level called "structural infix" which 007 doesn't really have. (But might when it gets for example Perhaps it would make sense to attach some metadata to precedence levels? That's a very unfinished thought, so I'll just leave that as it is. |
Just noting in passing that this could be handled by adopting the
I think we should adopt the |
I came here to make that same observation again, not knowing whether I'd made it before. It is possible that infixes are "simple" enough (just an array of literal strings, right?) that a parsed |
Another thing. This blog post at 2ality explains how the new JavaScript logical-assignment operators ( The reason for this (as explained in that post) is that the original logical operators are all short-circuiting, and the assignment versions should be too. Interestingly, Raku does not go this route — a synopsis has a phrasing that amounts to "macroish operators lose their short-circuitingness as they are turned into assignment operators". That may be consistent, but it's not strangely consistent, if you see what I mean. I much prefer JavaScript's strategy here, even though it clearly means having two separate rules. |
Actually, it's because it's too fiddly. (Duh!) But this actually does solve the whole thing, like providing a base case against an infinite recursion; each thus created metaoperator only acts on operators which are not fiddly, but the created metaoperator itself is too fiddly and therefore not subject to further meta-ing. |
I'm thinking we first do this one behind a feature flag, then (when we have modules) as a pragma that flips on the feature flag, and finally as a pure-007 parser-changing module.
It'll need to be implemented using something like a "what are all the allowable infixes" hook, which adds all the assignment infixes in a dynamic-enough way that (say) defining a new ordinary infix
op
immediately makes the correspondingop=
form available.Also, remember that the parsing of
op=
is such that the entire rest of the expression has invisible parentheses. So, for exampleThe text was updated successfully, but these errors were encountered: