Re: [Bug-apl] jot dot jot dot?

[Juergen Sauermann]

Hi, yes. I made multiple dyadic operators like ∘.∘.+ parse as (∘.∘).+ rather than ∘.(∘.+) /// Jürgen On 06/29/2016 10:33 AM, Jay Foad wrote: Can you explain what cases you have fixed? All the cases I showed seemed to working correctly already in GNU APL. Thanks, Jay. On 28 June 2016 at 19:09, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi, thanks, fixed in SVN 620. /// Jürgen On 06/28/2016 01:23 PM, Jay Foad wrote: The APL2 manual (p35) says "The right operand of a dyadic operator is the function or array to its immediate right." This is their way of saying that operator expressions are left-associative. For example, in ∘.∘.+ the right operand of the leftmost dot is ∘ (not ∘.+); so ∘.∘.+ is parsed as (∘.∘).+ The fact that operator-operand expressions are left-associative while function-array expressions are right-associative is one of the beautiful symmetries of APL! Some more examples demonstrating the left-associativity of operator expressions:       ≡⊂⍣4⍣6⊢'hello' 25       ≡(⊂⍣4)⍣6⊢'hello' 25       ≡⊂⍣(4⍣6)⊢'hello' DOMAIN ERROR       ⎕FX'R←(F L G)Y' 'R←F Y' L       ⎕FX'R←(F R G)Y' 'R←G Y' R       + L × R - 33 ¯33       (+ L ×) R - 33 ¯33       + L (× R -) 33 33 Jay. On 27 June 2016 at 12: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 >