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 <jay.f...@gmail.com> wrote: On 15 March 2016 at 13:24, Elias Mårtenson <loke...@gmail.com> wrote: > On 15 March 2016 at 21:14, Jay Foad <jay.f...@gmail.com> 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?