[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juergen Sauermann
Subject: Re: [Bug-apl] Rank operator and function assignment
Date: Sun, 09 Mar 2014 13:36:11 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi Kacper,

see some comments inline below.

On 03/04/2014 10:52 PM, Kacper Gutowski wrote:
On 2014-03-04 18:53:29, Juergen Sauermann wrote:
They say that f ⍤y is a function which is then called with arguments B and
possibly A.
Thus Z is a value and not a function; the function is created internally.
I guess the problem is that GNU APL doesn't really have what most people
understand under lambdas even though it supports dfns syntax.  Functions
are not a first-class values.
Yes, GNU APL only supports a limited subset of lambdas,
Not sure though how this is related to how the rank operator is computed.
The problem with ⍤ is its ambiguity regarding y.
y is expected to be a vector with 1, 2, or 3 elements.
Perhaps as a result of the earlier, you can not even disambiguate rank
arguments with parentheses this way (this works in other systems):

       (+⍤1) 2 3 4 5
       (+⍤1)2 3 4 5
        ^  ^
This rank error is thrown because +⍤1 is a valid phrase and is reduced first, like in:


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.

By the way, while Elias's example was correctly parsed and interpreted,
I think that parsing is not correct:

       +⍤1 +2 3 4 5
       +⍤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 which then throws the domain error:

     +⍤3 4 5 6
      +⍤3 4 5 6

If you had set the parentheses as suggested then you would have gotten the proper result:

      +⍤1(+2 3 4 5)
2 3 4 5

which is the same as:

      +⍤1(2 3 4 5)
2 3 4 5

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

For pattern fun ⍤ j B (A ⍤ j B handled accordingly):

1. j B is reduced to value C (because Vector binding is stronger than the others in IBM APL2).

2. fun ⍤ C is computed. There are two valid cases:

2a. ↑C is nested. In that case ↑C is taken as j and the reso of C as B
2b. ↑C is simple then C should be a vector whose last element is taken as B and the others as j.

Additionally, in A+, but also in Dyalog and NARS as I just checked, there
is a monadic ⊢, i.e. an identity function.  It is useful exactly for
this purpose, as it allows writing: +⍤1⊢2 3 4 5.  Monadic ⊢ could also be
used to display shy result regardless of type as in ⊢X←anything.
It's overall pretty nice consistent extension that I'd be happy to see
in GNU APL too.
I can look into this, but it seems to do the same as +⍤1(2 3 4 5). So it saves a parenthesis at the expense of an operator. However, in GNU APL 1(2 3 4 5) is computed at ⎕FX time, while ⊢ is
computed at runtime, which makes it slower.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]