Re: [Bug-apl] A few problems

[Dr . Jürgen Sauermann]

On 02/06/2019 05:11 PM, vvs wrote: On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: Certainly not: ∇Z←A Z←42 ∇ 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 the invention of APL. You need to )ERASE A (or → if A was localized) before you can change it I don't see any mention of this in ISO standard or any textbooks. Where exactly is said that parsing should always use token class when binding names? I'm again quoting ISO where it explicitly said that tokens could change their class during parsing: "Informal Description: Bind-token-class is used to bind each identifier in current- statement to its current syntactic-unit; if the class of a token changes between this point and the time the token is used (as it would for example in F ⎕EX'F' , assuming F were initially a defined-function), the change will be detected and reported as a syntax-error in the appropriate phrase-evaluator." I understand wordings in ISO such that as parsing should always be done based on syntax alone and only evaluation of already parsed expressions should consult their classes. In that context A is clearly a variable-name and only during binding it should be signaled that changing its class is a syntax-error. Otherwise evaluating syntactically incorrect statements will surely lead to unpredictable behavior. Yes. I would phrase it slightly differently: bind changes token of class simple-identifier to one of the token classes Variable-Name, Defined-Function-Name, Defined-Operator-Name, etc.. From that one cannot conclude that bind (and hence parse) would be allowed to change e.g. a token of class Defined-Function  to a token of class Variable, (and how would it?). That is, * bind can change class simple-identifier to something else (depending on the current context);   the result could be Variable-Name but also some Defined-Function-Name * Assignment changes either nil or else Variable-Name (but no other such as Defined-Function-Name)   to Variable. That means that a token of class simple-identifier is converted to e.g. token variable in 2 steps: the first step (bind) classifies the name, and the second step (assignment) converts it to the final token variable, Each step is restricted in terms of the token classes that can be changed, and a violation of the rules results in a syntax error, In that respect NARS is not ISO compliant, but nobody else is because ISO contains a number of failures which makes it impossible to be 100% compliant.