bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] A few problems


From: Dr . Jürgen Sauermann
Subject: Re: [Bug-apl] A few problems
Date: Thu, 7 Feb 2019 13:16:39 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1


On 02/06/2019 05:24 PM, vvs wrote:
On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann
<address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]