Hello Jürgen and thanks for the explanation.
Based on what you just explained, I would have assumed the following to
work?
* m (/⍨) 2 = +/[1] 0 = m ∘.| m←⍳N*
LENGTH ERROR
m(/⍨)2=+/[1]0=m∘.|m←⍳N
But this variation works?
* m (/⍨) (2 = +/[1] 0 = m ∘.| m←⍳N)*
2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97
Regards,
Elias
On 26 November 2014 at 21:45, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi again,
>
> I have analyzed this a bit further. Below are my conclusions.
>
> 1. Problem description
> --------------------------------
>
> Elias' initial question can be reduced to this: Given APL values *A* and
> *B*, say
>
> * A←1 2 3 4 5 *and
> * B←1 1 0 1 0*
>
> how shall the following expressions be evaluated:
>
> * A /⍨ B*
> * A (**/⍨) B*
> * (A) /⍨ B*
>
> The matter is a bit complicated by the ambiguity of the */ token*:
>
> For historical reasons the token */ *is ambiguous and could mean the
> dyadic function compress or
> the monadic operator reduce. GNU APL resolves this ambiguity at *⎕FX *time
> when possible. For example,
> in *1 2 3 / B *the operator */* is "downgraded" from "operator reduce"
> to "function compress" because *1 2 3 *is a value
> and therefore only function compress makes sense. However in *A / B* it
> is not known at *⎕FX* time whether *A* is a function
> or a value. In that case a symbol is assumed to be a function (and hence /
> an operator) while something in parentheses like
> *(A)* is assumed to be a value. That is the reason why *A /**⍨** B* gives
> a syntax error while *(A) /⍨ B* does not. IBM APL2 also
> downgrades */ *from operator reduce to function compress, but at a later
> time.
>
> The behavior of IBM APL2 in that special case is somewhat sub-optimal
> because insisting in / being an operator even
> if it is obviously not leads to the following inconsistency:
>
> IBM APL2:
>
> *1** (+¨) 1*
> *2*
> *1** (/¨) 1*
> *SYNTAX ERROR*
>
> GNU APL:
>
> * 1 (+¨) 1*
> *2*
> * 1 (/¨)1*
> * 1*
>
>
> 2. Alternatives
> ---------------------
>
> I have tested what happens if we would introduce a *M M* pattern into GNU
> APL in order to
> get IBM APL2's behavior. In the above examples (I used ¨ instead of Elias'
> original ⍨ because ¨ is
> present in IBM APL2 while ⍨ is not). *(+¨) *is reduced by a pattern *F M
> *(function
> monadic-operator) to a
> derived function. In contrast *(/¨) *is not reduced because there is no *M
> M* pattern (except in the cases where
> / was downgraded). The *M M* is shifted rather than reduced and the
> first *F *in a sequence *F M M* ... causes
> the whole chain to be unrolled from left to right, This is the difference
> that Jay has observed between IBM APL2
> and the others.
>
> Adding a *M M* rule forces the parser to reduce *M M* immediately rather
> than shifting it. After doing that, a few regression
> testcases did fail. Looking at the test results my impression was that the
> current behavior of GNU APL is the preferred one.
>
>
> 3. Conclusion
> --------------------
>
> My conclusion so far is that we should leave things as they are.
>
> Putting things in parentheses is, in my opinion, not such a bad thing and
> it makes programs more explicit and more portable.
>
> When choosing between:
>
> * A (**/⍨) B* and
> * (A) /⍨ B*
>
> I would recommend the former because that expresses better what is desired
> and the latter may change at some point in time.
>
> /// Jürgen
>
>
>
> On 11/25/2014 04:01 PM, Juergen Sauermann wrote:
>
> Hi Jay,
>
> yes, what I meant is that / is called like a dyadic function as in 1 1 1 /
> 1 2 3.
>
> But handling it always like an operator could be a better solution.
> Currently in GNU APL operators are distinguished from functions which
> works well
> except for / and friends which are parsed as function in some contexts and
> parsed as operator in others.
>
> I will look into changing this to making operators accept a non-function
> left argument.
>
> /// Jürgen
>
>
>
> On 11/25/2014 03:33 PM, Jay Foad wrote:
>
> On 25 November 2014 at 14:06, Jay Foad <jay.f...@gmail.com>
> <jay.f...@gmail.com> wrote:
>
> On 25 November 2014 at 13:38, Juergen
> Sauermann<juergen.sauerm...@t-online.de> <juergen.sauerm...@t-online.de>
> wrote:
>
> I have read the IBM binding rules a number of times but they seem not to
> help. The problem of these rules is
> that they give different results in the cases where / is an operator and
> where / is a function.
>
> In IBM APL2 / is always an operator.
>
> For example:
>
> 1 2/¨3 4 ⍝ GNU APL, NARS2000 and Dyalog: parse as 1 2(/¨)3 4
> 3 4 4
>
> 1 2/¨3 4 ⍝ APL2: parse as (1 2/)¨3 4
> 3 3 3 4 4 4
>
> Jay.
>
>
>
>
>
