In APL2 this is not a problem, because / et al are always operators:
1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
3 3 3 4 4 4
1 2 /¨ 3 4 ⍝ in GNU APL this parses as 1 2 (/¨) 3 4
3 4 4
Jay.
On 14 March 2016 at 13:03, Juergen Sauermann
<juergen.sauerm...@t-online.de> wrote:
> Hi Kacper,
>
> yes. The tricky case is when it cannot be decided if g is an operator or
> not.
>
> Consider this:
>
> 1 (+//) 1 2 3 4
> 1 2 3 4
>
> We get the same result in GNU APL and IBM APL2. No idea what Dyalog
> APL returns in this case.
>
> The +// can then be interpreted in two different ways:
>
> a) function-plus operator-reduce operator-reduce
> b) function-plus function-compress function-compress
>
> Of course one could resolve this by deciding for either a) or b).
> But: if we go for b) then we introduce an incompatibility with IBM APL2,
> and if we go for a) then we have a syntax with exceptions for / \ ⍀ and ⌿.
>
> I consider both options as really really bad and not worth the effort for
> implementing
> them.
>
> /// Jürgen
>
>
> On 03/13/2016 07:35 PM, Kacper Gutowski wrote:
>
> On Sun, Mar 13, 2016 at 6:20 PM, Juergen Sauermann
> <juergen.sauerm...@t-online.de> wrote:
>
> it actually does create conflicts.
>
> In IBM APL2 and in GNU APL, the expression
>
> ⍺ (f g h) ⍵
>
> gives a 3 item vector with the items being ⍺, (f g h), and ⍵.
> In Dyalog APL it gives (quote):
>
> (⍺ f ⍵) g (⍺ h ⍵) ⍝ dyadic (fgh) fork
>
> I'm not certain whether it does create conflicts or not in general,
> but I think this particular example is flawed: ⍺ (f g h) ⍵ could be
> anything depending on what name classes those symbols have
> (particularly if g were an operator). When f, g, and h are all
> functions, then it's not a vector, but a syntax error. No conflict
> here.
>
> -k
>
>
