Hello
Sorry for opening a new post above, I did not realize this was already
being discussed here.
I'm far from being an APL expert, but I humbly believe the current behavior
to be a bug. Consider this expression, where A and B are arrays (or
scalars):
A F / B
If F is a function, then / should perform N-wise reduction (ISO 13751
§9.2.3, shown being used without parentheses.) But if F is an array, then A
F is a nested array and / should perform the replicate function (§10.2.5,
again shown being used without parentheses.)
I'm not sure if the ambiguity inherent in the symbol / (and others) is
mentioned anywhere in the standard. But I'm quite sure other APL
implementations solve the issue by always treating / and other such symbols
as operators.
When such an operator receives an array as the left operand it will perform
replication; otherwise it will perform reduction.
This is also the only way an APL programmer may define a symbol like that,
because a given name may only be defined to be either a function or an
operator, not both.
Tobia
On Thu, Nov 27, 2014 at 10:56 AM, Jay Foad <jay.f...@gmail.com> wrote:
> Hi Jürgen,
>
> Thanks for doing the analysis.
>
> > 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.
>
> I don't understand this bit. Monadic operators don't bind like this in
> APL2.
>
> Surely the way to get APL2 behaviour is:
> - never downgrade / to a function
> - introduce an A M pattern to allow operators to have arrays as left
> operands
>
> Jay.
>
>
