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
>>> >
>>>
>>>
>>>
>>
>>
>
>
