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
<address@hidden> 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.