Re: [Bug-apl] Rank operator and function assignment

[Kacper Gutowski]

On 2014-03-09 13:36:11, Juergen Sauermann wrote:
> Not sure though how this is related to how the rank operator is computed.

Related to how it is parsed, because in NARS2000 there is no difference
for operator's syntax whether its operands are functions or some other
values.  Functions might not be a first-class values, but in some places
they are not distinguished from other values.

> This rank error is thrown because +⍤1 is a valid phrase and is
> reduced first, like in:

In NARS2000, +⍤1 is not a complete statement; when typed alone it will give
a syntax error because it's a function without an argument.  It's equivalent
to {+⍤1⍵} (or {⍺+⍤1⍵} when used dyadically):

  F←+⍤1 ◊ F 2 3 4 5  ←→  +⍤1 (2 3 4 5)  ←→  (+⍤1) 2 3 4 5


> This raises the question if we should allow an operator like ⍤ to
> change the syntax of the language
> in order to work. To achieve the desired effect of binding 1 to +⍤
> we would then need to handle
> 'fun op B' in one way if op is ⍤ and in another way if not. even
> though that is implementable,
> i am hesitant to do it because IMHO it obscures the syntax of the language.

The change is not to treat ⍤ in any special way, it's to allow a vector
to be an argument of operator.  These forms are syntactically parallel:

  4∘.=+3 4 5  ←→  4 ∘.= (+3 4 5)
  4+⍤1+3 4 5  ←→  4 +⍤1 (+3 4 5)  ⍝ currently not true in GNU APL

“1” and “=” are syntactically in the same place in this example.  The
only difference is that the right operand of ∘.f is a function and f⍤y
takes a vector.

I'm not entirely sure this is a good change to make in GNU APL, but
existence of ⍤ operator mandates it.

Rank is a strange operator that takes a vector as right operand rather than
a function.  This by itself changes syntax of the language.  But in NARS2000
and Dyalog (Dyalog has e.g. ⍣ that also can take number as operand) it simply
follows the same consistent rules that apply to functional arguments of all
the other operators.

In NARS2000 and Dyalog APL, I can do this:

      ∇Y←A (f FF g) B
[1]  Y←A f g B
[2]  ∇
      3 +FF- 5
¯2
      3 (+FF 5) 6  ⍝ sic, g←5
8 9
      3 +FF 5 +6
8 9
      3 (4 FF 5) 6
3 4 5 6


> >       +⍤1 +2 3 4 5
(…)
> >It is expected to be parsed as +⍤1(+2 3 4 5) and it's not ambiguous at all.
> >I can't find it in the spec right now, but cf. ∘.=⍨ which is (∘.=)⍨ not 
> >∘.(=⍨).
> >Correct me if I'm wrong, but afaiu, operators, unlike functions, should be
> >left associative.
> It is actually parsed as +⍤(1 +2 3 4 5) which becomes +⍤3 4 5 6

Yes, exactly, I see what happened.  That's why I gave the example of
∘.=⍨ to show that operators should not take everything to the right as
their right operand.  The interpretation of +⍤(1+2 3 4 5) would be
expected iff ⍤ were a function rather than operator (it would be used
monadically in this example) or monadic operator without right argument
at all (which is the case but I didn't know that before).


> Generally speaking, GNU APL computes the rank operator like this:

In other words, in GNU APL:

  +⍤1 (2 3 4)  ←→  +⍤ (1,⊂2 3 4)

This explains a lot.  I thought that ⍤ is a dyadic operator with right
operand being vector, because that is how other systems treat it.  But
GNU APL, instead of allowing right operand to be numeric, makes ⍤ a
monadic operator that treats right argument of the derived function in
unusual way.

That's a clever hack around the syntax that allows only functions as
arguments of operators.


-k