is `as` a reserved token?

[apblack]

In the spec, as is listed as one of the reserved tokens.

Is this what we want? Historically, minigrace has treated as specially; it was a keyword in the import statement, but was also allowed as an identifier. This behaviour is inconsistent, but also convenient.

Many other reserved words really have to be reserved. For example, if dialect is not reserved, then

    dialect "beginningStudent"

might be a request of the method dialect with a string argument. Do we want to allow some keywords to be reused as identifiers? Or is that madness?

[KimBruce]

I’ve always tended toward the view that keywords should be reserved words (i.e., treated specially, not allowed as identifiers). In particular it is better to go that direction early as going from keywords to reserved words later will break code, while going the other direction is easy.

While not exactly the same issue, I still remember the old FORTRAN bug where making a typo so that DO 10 I = 1,10 becomes DO 10 I = 1.10

changes a for-loop into an assignment statement. I believe that was supposed to have resulted in sending some rocket off in some bizarre way.

In our case, I’d hate to try to read

import “as” as as

So please, let’s leave it as it is in the spec!

Kim

On Nov 17, 2017, at 9:17 AM, Andrew Black notifications@github.com wrote:

In the spec, as is listed as one of the reserved tokens http://web.cecs.pdx.edu/%7Egrace/doc/lang-spec/#reserved-tokens.

Is this what we want? Historically, minigrace has treated as specially; it was a keyword in the import statement, but was also allowed as an identifier. This behaviour is inconsistent, but also convenient.

Many other reserved words really have to be reserved. For example, if dialect is not reserved, then

dialect "beginningStudent"

might be a request of the method dialect with a string argument. Do we want to allow some keywords to be reused as identifiers? Or is that madness?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/132, or mute the thread https://github.com/notifications/unsubscribe-auth/ABuh-vz2wSSXy1A7UTwyVyjKjHB8Y3Cxks5s3b--gaJpZM4QiWxf.

[apblack]

This is my inclination too. It just means that several of the minigrace compiler files are not actually legal Grace!

[kjx]

import “as” as as

Touché!

C# calls these things "contextual keywords" - they wanted to expand the language and not break anything. We can and should do without.

If mg accepts them though, that's not the end of the world - there are no doubt many more pressing things to fix.

James

[apblack]

I've actually know about this issue for a while, but had delayed dealing with it because removing a feature from minigrace is such a pain when that feature is used by minigrace itself.

Now that I have a second parser (SmallGrace) that can detect the misuses of as, it was fairly easy to find and replace them all. So I'm now adding as to the list of reserved words, and making the corresponding change to the parser.

I have to say that I sometimes wish that I could use is and as as parts of a method name. On the whole, though, I do agree that making all uses of the reserved tokens for other purposes uniformly illegal is the right thing to do.

The change is in minigrace commit b6878e44

[kjx]

On 20/11/2017, at 4:52AM, Andrew Black notifications@github.com wrote:

I've actually know about this issue for a while, but had delayed dealing with it because removing a feature from minigrace is such a pain when that feature is used by minigrace itself.

well yep.

Now that I have a second parser (SmallGrace) that can detect the misuses of as, it was fairly easy to find and replace them all. So I'm now adding as to the list of reserved words, and making the corresponding change to the parser.

Moth is using the Kernan-derived Jernan parser. (Checks Kernan) hmm, Kernan treats "is" as a reserved word, but not, it appears, "as"

I have to say that I sometimes wish that I could use is and as as parts of a method name. On the whole, though, I do agree that making all uses of the reserved tokens for other purposes uniformly illegal is the right thing to do.

well it's a choice, and the "simplest thing that could probably work" Wirth would agree. still it's something to think about if e.g. we try to parse amg with Jernan

James