Re: [Bug-apl] A few problems

[Dr . Jürgen Sauermann]

On 02/06/2019 05:24 PM, vvs wrote: On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: At this point A has token class Niladic-Defined-Function-Name (page 25), An attempt to change that by: A←5 is therefore explicitly forbidden by the statement on page 67. It has always bin that way since And BTW in any functional language these two definitions are completely independent of each other. It's just a coincidence that the same name was used for different binding. Depending on rules and scoping one definition could or could not shadow another, i.e: A←0 A←1 these are different tokens that just happen to reuse the same name. And only if that binding changes a token class, then it should be considered a syntax-error. Describing cases in different statements ist just a way to simplify them. You can always pack them into a single statement: ⊣(A←1), A←0 In The ISO case both A would bind to nil. In thei APL interpreters that I know best (FNU APL and APL2) it seems like the binding takes place while the statement is being parsed and not (as ISO believes) before the statement is executed, In that case the rightmost Token has class nil while the leftmost has class variable-name. There is a number of cases where the ISO standard says one thing and IBM APL2 behaves differently. In almost alll pf these cases, the implementation of GNU APL has followed IBM APL2, because I believe that compotiibility with an existing interpreter has more value to the user than compatibility with a standard that nobody has implemented completely.