Operators are evaluated from left to right in Dyalog, NARS2000, and J at least.
This seems logical:
+/{each} should parse as (+/){each}, not +(/{each}), and +/{rank}1 as
(+/){rank}1, as "tacit" operators aren't supported in GNU APL or the standard
(/{each} and /{rank}1 have no meaning).
The problem is that jot dot is not a usual operator since it is written to the
left of its argument. I believe this is because it was originally perceived as
similar to an inner product, but with no reduction, and jot was the "null
function" (this comes from the original APL book). Inner products were written
with the first function on top of the second, but to adapt this to terminals, a
dot was instead placed between the two functions.
Thus °| became º.|
I would imagine jot dot should parse just like and inner product, except when
the jot is read, an outer product is executed. So, as I see it (with * as
times), °.°.* should parse as (°.°).*, just as +.*.* should parse as (+.*).* .
However, I don't see what (°.°) corresponds to.
It seems to me that APL2 parses it as
°.(°.*) , in which case APL2 has some operators with a long left scope and
others with a long right scope. Then you encounter problems such as °.*/; is
that °.(*/) or (°.*)/ ?
My point is that I am almost sure that functions have a long right scope, and
operators a long left scope; the exception here is jot dot, and I don't know
what it has. To illustrate what Iverson thought, in J x (jot dot fun) y is
written as x (fun/) y .
Louis
Sorry for the poor formatting!
> On 27 Jun 2016, at 13:37, Juergen Sauermann <juergen.sauerm...@t-online.de>
> wrote:
>
> Hi,
>
> not sure. First of all, both IBM APL2 and GNU APL return the same result in
> Alex's example:
>
> 5 ∘.∘.+ 9
> 14
> 5 (∘.∘).+ 9
> 14
> 5 ∘.(∘.+) 9
> 14
>
> Then the IBM language reference says this (p. 35):
>
> "For example, the function expression +.×/ is a reduction by a +.× inner
> product
> because the × binds as right operand to the array product operator (. ), and
> not as
> left operand to the slash operator (/). The + binds as left operand to the
> dot; then
> the resulting product binds to the slash as its left operand.
>
> +.×/ ←→ (+.× )/ not + .(× /)
> "
>
> However, the binding strength resolves the ambiguity in the IBM example only
> because / is not a dyadic operator. In Alex's example the operator is dyadic,
> and one
> could either bind the middle ∘ to the left ∘ or the + to the middle ∘ without
> violating
> the binding strengths. In this case I would argue that the "basic APL2
> evaluation rule"
> should be applied because ∘.+ can be evaluated (yielding a derived function)
> because all arguments
> of . are available before the . and ∘ on the left show up.
>
> What is missing in both the ISO standard and in the APL2 language reference
> is a
> statement about left-to-right or right-to-left associativity of APL
> operators. I personally
> would find it counter-intuitive if functions are evaluated left-to-right
> while operators are
> evaluated right-to-left.
>
> /// Jürgen
>
>
>> On 06/27/2016 11:48 AM, Jay Foad wrote:
>> So it looks like GNU APL parses ∘.∘.+ as ∘.(∘.+).
>>
>> IBM APL2 and Dyalog appear to parse it as (∘.∘).+.
>>
>> Jay.
>>
>> On 15 June 2016 at 04:05, Xiao-Yong Jin <jinxiaoy...@gmail.com> wrote:
>>> Hi Alex,
>>>
>>> It is correct. You need nested vectors to see the effect.
>>>
>>> Try the following.
>>>
>>> (⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2 3⍴⍳6)
>>>
>>> Best,
>>> Xiao-Yong
>>>
>>> > On Jun 14, 2016, at 6:39 PM, Alex Weiner <alexwei...@alexweiner.com>
>>> > wrote:
>>> >
>>> > Hi Bug-APL,
>>> >
>>> > Surely this is not correct:
>>> >
>>> > 5∘.∘.+9
>>> > 14
>>> >
>>> >
>>> > I would expect a syntax error.
>>> > If this is valid, then I stand corrected
>>> >
>>> > -Alex
>>> >
>
