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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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
>