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

[Louis de Forcrand]

The reason Dyalog is doing weird stuff with the jot is that it uses jot to bind 
left or right arguments (1 jot + = increment) AND for composition in its tacit 
style. It must have very complicated parsing rules.

What I would suggest is:
All operators have a long left scope, except jot dot, which takes as its right 
(and only) argument the whole chain of jots and dots to its right up to and 
including the first function:

jot dot jot dot jot dot + / each
would parse as
((jot dot (jot dot ( jot dot +))) /) each

This would produce maximum compatibility, since (jot dot jot) doesn't mean 
anything according to the standard anyway, and APL2 clearly states that
jot dot + / 
is
(jot dot +)/
not
jot dot (+/) .

Louis

> On 28 Jun 2016, at 18:20, Xiao-Yong Jin <address@hidden> wrote:
> 
> 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 <address@hidden> 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 <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
>