[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Operator binding
From: |
Jay Foad |
Subject: |
Re: Operator binding |
Date: |
Wed, 2 Dec 2020 16:40:29 +0000 |
Great, this sounds like exactly the right thing to do if you're aiming
for APL2 compatibility.
Dyalog has to jump through some hoops when it parses 2//B, to treat
the first / as a function but the second / as an operator. APL2's
parsing rules are much simpler.
Jay.
On Wed, 2 Dec 2020 at 16:27, Dr. Jürgen Sauermann
<mail@jürgen-sauermann.de> wrote:
>
> Hi,
>
> in following up the recent email discussions with Jay Foad and Hans-Peter
> Sorge,
> I have changed the operator-to-operator binding in GNU APL. SVN 1367.
>
> Before the change an expression with 2 adjacent operators,
> for example 2 / / 3 4⍴5, would have given this:
>
> B←3 4⍴5
> 2 / / B
> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5·
> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5·
> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5·
>
> GNU APL would have bound the left / to the right / and evaluation
> the expression with:
>
> * the left / being function compress, and
> * the right / being operator reduce with function compress as left operand.
>
> After the change the same expression now evaluates to:
>
> B←3 4⍴5
> 2 / / B
> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
>
> GNU APL now binds 2 to / as discussed earlier. This creates a derived
> function,
> say TWICE, like:
>
> ∇ Z←A TWICE B
> ⍝ A not used
> Z←2 / B
> ∇
>
> and then reduces TWICE with B:
>
> TWICE / B
> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
>
> Interestingly:
>
> * as seen above, TWICE / B and 2 / / B now give the same result in GNU APL,
>
> * TWICE / B gives the same result in GNU APL and in IBM APL2,
> but: 2 / / B gives a DOMAIN ERROR in IBM APL2, and
>
> * TWICE / B also give the same results in GNU APL and in Dyalog APL,
> but Dyalog APL gives a different result (apparently the same as the old
> GNU APL implementation) for 2 / / B (from tryapl.org):
>
>
> B←3 4 ⍴ 5
> TWICE←{⍺ ⊢ 2/⍵}
> TWICE / B
> ┌───────────────┬───────────────┬───────────────┐
> │5 5 5 5 5 5 5 5│5 5 5 5 5 5 5 5│5 5 5 5 5 5 5 5│
> └───────────────┴───────────────┴───────────────┘
>
> 2 / / B
> ┌─────────┬─────────┬─────────┐
> │5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
> ├─────────┼─────────┼─────────┤
> │5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
> ├─────────┼─────────┼─────────┤
> │5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
> └─────────┴─────────┴─────────┘
>
> That suggest that the binding of operators is not very portable
> between interpreters and one should not rely on them in the first
> place. It seems to be more reliable bind explicitly as shown above
> as to avoid unexpected surprises later on.
>
> Best Regards,
> Jürgen
>
>
>
>
>
>
>
>
>
- Operator binding, Dr . Jürgen Sauermann, 2020/12/02
- Re: Operator binding,
Jay Foad <=