At any rate, is there any reason why the assignment state shouldn't
behave more like a function which responds to operators (there might
be - I'm just asking)? In other words, this doesn't work:
←/a b c 0
This does:
a←b←c←0
Of course, I already know you could simply write this:
a b c←0
But I still have my question. Why shouldn't the first example work?
You (and maybe I) may regret this but here is a sort of an answer.
Your statement could only work, if at all, if a, b & c already existed
because the right argument to the assignment reduction would have to
be parsed first. Therefore it can't work because that argument will
then contain the _values_ of a, b & c, not their names or addresses.
This works:
+z←3
3
+z∘←⍣0+7
7
z
3
+z∘←⍣1+11
11
z
11
Here the assignment into z is an operand to the power operator and is
conditional upon its right operand, the boolean value 0 or 1.
This works because the left operand to power is ambivalent and
assignment, contrary to expectation, is monadic, its name being bound
to it.
For assignment reduction to work assignment would have to be dyadic;
the operand to reduction being strictly so.
In fact this _is_ possible by using another trick: binding the
assignment (z∘←) to the identity {⍵} giving {⍵}∘(z∘←) which, though
ambivalent, ignores its left argument.
+z←4
4
+{⍵}∘(z∘←)/23
23
z
4
+{⍵}∘(z∘←)/1 51
51
z
51
The first of these has no effect because any reduction on a scalar
returns that same scalar unchanged _without_ running the function. The
second runs it between 1 & 51, ignores the 1 and assigns the 51.
OK?
As for strand (multiple) assignment, I prefer the APL2 or []ml 3
syntax, namely
(a b c) := 0
To me this is much clearer.
a b c := 0
is ambiguous, if a exists and b is a function.