Re: [Bug-apl] Bug in the parser?

[Tobia Conforto]

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 <address@hidden> 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.