Re: [Bug-apl] Feature suggestion: multiple function arguments

[Juergen Sauermann]

Hi,

maybe, maybe not.

it seems like in APL2, / and friends (⌿ \ and ⍀) are always operators.

In GNU APL / and friends are operators if their left argument is a function, and
functions if their left argument is a value.

That's why 1 2 /¨ 3 4 is evaluated directly and without a derived function in GNU APL.

The ISO standard lists Z←A/B and Z←A\B as mixed functions replicate (section 10.2.5) and expand (section 10.2.6),
and clearly not as operator (section 9).

I would also argue that there are good reasons for GNU APL to behave as it does (despite of
its APL2 incompatibility). Consider this:

      1 2 /¨ 3 4
 3  4 4
     
      Compress←{ ⍺ / ⍵ }
      1 2 Compress ¨ 3 4
 3  4 4

No surprize, right? But if we would always treat / as an operator, then the above would give two
different results and that would, in my opinion, be rather counter-intuitive.

And the syntax error is a mere consequence of / being a function in the example (you
cannot bind a function to its left argument with ().

/// Jürgen

On 03/15/2016 03:54 PM, Elias Mårtenson wrote:

On 15 March 2016 at 22:47, Jay Foad <address@hidden> wrote:

On 15 March 2016 at 13:24, Elias Mårtenson <address@hidden> wrote:
> On 15 March 2016 at 21:14, Jay Foad <address@hidden> wrote:
>>
>>       1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
>>  3 3 3  4 4 4
>
> Are you saying that (1 2 /)¨ 3 4 is syntactically correct in APL2?

Yes. / is an operator, so 1 2/ is a derived function, and you can
parenthesise any function-valued _expression_.

So is the SYNTAX ERROR from GNU APL here a bug then?