Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Assignment statement comment

3 views
Skip to first unread message

pineapple

unread,
Sep 4, 2009, 3:26:56 AM9/4/09
to
First, I'd just like to admit up front that this is largely
meaningless and irrelevant.

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?

Phil Last

unread,
Sep 4, 2009, 8:49:44 AM9/4/09
to

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?

pineapple

unread,
Sep 4, 2009, 2:34:26 PM9/4/09
to
Interesting. Thanks for the analysis.

Nick

unread,
Sep 5, 2009, 4:33:45 PM9/5/09
to
Strictly speaking, you might get a an answer or a value error
depending on whether a, b, or c existed. If a or b or c already
existed but were functions, you could get a syntax error. Worse yet,
b could be an operator. From a design standpoint, this could get very
nasty very fast.

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.

0 new messages