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
Exploding an expression: interpretation of the ‘@’ modifier #1626
Comments
This is a great point.
As you said this is debatable.
This will need to be handled as a special case and not as a result of precedence rules so I am not quite inclined to do that. (Edit: not quite inclined) My takeaway from this is that the entire I am also considering just removing the # This looks fine: $x is already a list and this is setting its content
set x[@] = a b c
# This can work but feels wrong; $x doesn't exist yet, why is it getting indexed?
var x[@] = a b c
# One might expect this to work out of analogy, but what should it do?
var x[1] = a
# This also feels wrong...
fn {|a b rest[@]| ... } |
Hmm. I also feel a bit uncomfortable with If we're investigating alternate syntaxes, I was wondering if just using
The main argument against, perhaps, is that Whatever the syntax, one advantage is that this could be applied to several levels at the same time: |
Aye, there's the rub. That is so because the |
Lists already support slices too, which are also valid map keys.
It means indexing
Not just that; |
Now that I had time to let it sink in a bit, I think I could at least get used to the Perhaps, though, it might even be desirable to support both syntaxes? They don't clash with each other, but it does violate a language purist's principles to have two ways to say the same thing. In any case, I think that using explosion and indexing both on the LHS of an assignment should be made illegal, as the meaning of |
What if setting and getting had different syntaxes? Would that feel too weird?
|
To set the stage, for a variable
v
, the meaning of$@v
andset @v = value …
is clear:Note that
$@v
returns what we gave toset @v
.But involve some array references, and things are not as clear:
This breaks two reasonable expectations, IMO:
$⟨something⟩
should reflect the RHS of a previousset ⟨something⟩ = …
$@⟨something⟩
acts like syntactic sugar for(all $⟨something⟩)
Of course, this depends on what you see as the ⟨something⟩ in a compound expression. What is most jarring is the lack of symmetry between the assignment and the expansion.
So this is my suggestion:
Of course this is breaking change, so it needs to considered carefully. But I doubt there is much code out there that relies on the current behaviour.
$@variable[⟨index-expression⟩]…
by{$@variable}[⟨index-expression⟩]…
will result in the old behaviour. This should be fairly easy to automate. Also, since the result of such an expression is a bit tricky to figure out, I think the extra curly braces will help to make clear that something funny is going on.The text was updated successfully, but these errors were encountered: