I agree that in terms of the . operator, f.g.h should parse as (f.g).h. It seems more logical to treat ∘ as a function so ∘.∘.f parse as (∘.∘).f too, but perhaps APL2 is doing something special with ∘. as one operator?
Here is a session with Dyalog, ⎕ML←2 ⍝ Some high dimensional mind twist (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3 3.00060006J30.0060006 2.00080012J20.0080012 (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3 3.00060006J30.0060006 2.00080012J20.0080012 (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3 3.0006J30.006 6.0006J60.006 ⍝ ∘.∘ completely baffled me 1∘.∘.+2 3 1∘.∘.+2 3 SYNTAX ERROR: The function does not take a left argument 1∘.∘.+2 3 ∧ ∘.∘.+2 3 SYNTAX ERROR: The function requires a left argument ∘.∘.+2 3 ∧ Unfortunately, gnu apl fails at this f.g.h fun (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3 LENGTH ERROR μ-Z__A_LO_INNER_RO_B[5] (μ-IA μ-IB)←⊃μ-I[μ-N] ^ ^ )reset (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3 LENGTH ERROR μ-Z__A_LO_INNER_RO_B[5] (μ-IA μ-IB)←⊃μ-I[μ-N] ^ ^ )reset (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3 LENGTH ERROR μ-Z__A_LO_INNER_RO_B[5] (μ-IA μ-IB)←⊃μ-I[μ-N] ^ ^ Best, Xiao-Yong > On Jun 28, 2016, at 10:26 AM, Louis de Forcrand <ol...@bluewin.ch> wrote: > > 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 >>> > >>> >>> >>> >>