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

[Juergen Sauermann]

Hi Tobia,

the quick answer is this. Suppose we have:

A / ¨ B.

The the parser does this:

read B (no pattern match)
read ¨ (no pattern match)
read /

At this point we could:
(i) take / to mean (function) compress, bind / to ¨ and finally try A (/¨) B, or
(ii) take / to mean (operator) reduce and try (A/)¯B.

Both interpretations (i) and (ii) are in accordance with the ISO standard and also with the IBM APL2 binding rules.
In the special case above (i) will always give a valence error but in general (e.g. user defined operator instead of ¨)
we cannot know. And instead of A there could be an arbitrarily complex left hand side which was the reason why I tried
to resolve the nature of / at ⎕FX time.

/// Jürgen

On 12/29/2014 12:59 PM, Tobia Conforto wrote:

Thanks.

I understand that there is a tradeoff involving run-time lookahead. It's still not entirely clear to me why simple cases would parse correctly, even with a user-defined symbol as the left argument (A/B) while applying an operator would break the parser (A/¨B). I'll have to study the parser to understand the issue.

In the meantime, I propose adding an explanation to the docs (see attached patch) since it's an implementation choice that differs from some other well-known APL interpreters.

Tobia

On Sun, Dec 28, 2014 at 7:43 PM, Juergen Sauermann <address@hidden> wrote:

Hi Tobia,

I have fixed the special case

    {(2|⍵) / ⍵} ⍳3

 that you reported, SVN 519.

There remains a handful of border cases related to / ⌿ \ and ⍀ caused by the ambiguity of these symbols
because, for example, function / parses differently than operator /.

In order to avoid lengthy and complicated run-time lookaheads of the left argument of / and friends,
GNU APL tries to resolve this ambiguity at ⎕FX time. This works well except if the left argument is a
user-defined symbol, say U. In that case the rule in GNU APL is that (U) is assumed to be a value
while U alone is assumed to be a function. Then U/ takes / as an operator (and U/ a derived function),
while (U)/ takes / as a function and (U) i.e. U its left argument.

Neither the ISO standard nor the APL2 manual provide enough information to cleanly resolve these border cases.
I have tried the "/ is always operator" approach earlier but it was breaking quite a few GNU APL testcases
so I decided not to follow it.

/// Jürgen

On 12/28/2014 05:12 PM, Tobia Conforto wrote:

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.