Re: Operator binding

[Dr . Jürgen Sauermann]

Hi Elias,

On 12/2/20 6:22 PM, Elias Mårtenson wrote:
> On Thu, 3 Dec 2020 at 00:41, Jay Foad <jay.foad@gmail.com 
> <mailto:jay.foad@gmail.com>> wrote:
>
>     Great, this sounds like exactly the right thing to do if you're aiming
>     for APL2 compatibility.
>
>     Dyalog has to jump through some hoops when it parses 2//B, to treat
>     the first / as a function but the second / as an operator. APL2's
>     parsing rules are much simpler.
>
>
> I'm not sure it has to jump through any hoops. My experimental APL 
> parser returns the same result as Dyalog, and its parser is probably 
> as simple as it gets. It's a simple left-to-right recursive descent 
> parser with one token lookahead. In fact, I think achieving GNU APL's 
> new parsing style would be much more difficult.
As a matter of fact, this change has reduced the number of parsing rules 
(see *tools/phrase_gen.def* of the
different SVN versions). In early GNU APL I had tried to figure the role 
of / and friends statically in order to
remove some burden from the parser. That covered most cases, but was not 
reliable and the code to
doing that was somewhat complicated. At that time I was simply not aware 
of the strictness of the operator
vs. function in APL2 that Jay pointed out recently. I am grateful that 
matters have simplified now. even though
I am still a little alienated by concept of allowing arrays where 
functions should be (even for the right operand!).
> In GNU APL's case, it's probably the right way to go because APL2 
> compatibility is an important feature, but I don't think it's a 
> simpler approach.
>
> Regards,
> Elias