I see, thanks. I was thinking of the table "NAME AND SYMBOL BINDING"
on page 21 and repeated on page 34. It uses the neutral term "left operand"
without being specific whether that operand is a value, a function or an operator.
I read the sentence you quote somewhat differently. Not in the sense that
one operator cannot be the left or operand of another operator but rather that the
binding rules concerning operands of operators shall not apply if an operand is
itself an operator. The example that follows wisely excluded the case where
an operator like / could also be evaluated as a function.
I believe the sentence is equivalent to saying, in parser terms, that OP OP shall
be shifted rather than being reduced. That will unfortunately create more derived
functions, but these cases are so rare that that will not matter. I will therefore
see what happens if I remove all parser reductions with adjacent operators
from the phrase table of GNU APL and see if that causes new problems
(I suppose at least some automatic testcases will fail).
Best Regards,
Jürgen
On 11/30/20 1:25 PM, Jay Foad wrote:
My 1 / / 1 1 ⍴ 1example was only meant to demonstrate that in APL2 an operator can have another operator (in this case itself) as left argument. And in that case binding the leftmost 1 to the left / operator would be, at least IMHO and referring only to the language reference manual, as valid as binding the left / operator to the right / operator.I don't think so. See the discussion of "Name and Symbol Binding" starting on p33, and in particular on p35: "There is no binding between operators. In the _expression_ ,¨/ catenate binds as left operand to the each operator, and then the derived function ,¨ binds as left operand to the slash operator." Jay.
