Hi Elias,
On 12/2/20 6:22 PM, Elias Mårtenson wrote:
On Thu, 3 Dec 2020 at 00:41, Jay Foad <jay.f...@gmail.com
<mailto:jay.f...@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
