NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/acorn/8357

Internet Message Format | 1992-08-25 | 6.2 KB

Path: sparky!uunet!mcsun!uknet!acorn!armltd!dseal
From: [e-mail] (David Seal)
Newsgroups: comp.sys.acorn
Subject: Case of Basic keywords (was Re: OS differences and improvements...)
Message-ID: <[e-mail]>
Date: 26 Aug 92 08:52:29 GMT
References: <[e-mail]>
Sender: [e-mail]
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK
Lines: 116

In article <[e-mail]> [e-mail] (Geoff Lane)
writes:

>In article <[e-mail]> [e-mail] (Pete Goodwin) writes:
>>Still, I'm biased, I like the VMS command line: DIR, SET DEFAULT, TYPE, ED (I'm
>>a fan of EVE EDT), SEARCH, PRINT etc.
>>Pete Goodwin
>
>Never could trust a computer you had to shout at to get work done :-)
>
>Which brings me to RiscOs Basic. Why, Oh why, Oh why, Oh why do we still
>have to write the Basic commands and keywords in uppercase?

Probably because changing this would (a) be highly inconvenient; (b) make
old programs difficult to maintain, etc.

To explain: there is a rule in the Acorn Basics that a variable name may not
start with a keyword. This rule is there to make certain that the
interpreter can understand your programs. A simple example of this is a
statement like:

  unable%=NOTable%

Without the rule about variable names not starting with keywords, the
interpreter wouldn't be able to tell whether you were telling it to set
unable% to the variable NOTable%, or to the logical negation of the variable
able%. With the rule, it can easily determine that the latter is the only
legitimate interpretation.

This isn't too inconvenient, because the keywords are only recognised in
upper case. For instance, the variable name "TOTAL" is disallowed because
"TO" is a keyword, but you can quite easily use "Total" or "total" instead.
If you start recognising keywords regardless of case, however, it becomes a
lot more inconvenient: quite a few desirable variable names become
completely unusable.

On top of this, at present there are several useful rule of thumbs about
avoiding variable names which start with a keyword - e.g. "If your variable
names never start with more than one upper case letter, you'll never run
into the problem". No such easy rule of thumb exists if keywords are
recognised regardless of case.

Secondly, old programs would become very difficult to maintain, because they
would be likely to contain some of the now-forbidden variable names. This
wouldn't be a problem for the tokenised form in which Basic programs are
stored, because the tokenised form makes a clear distinction between e.g.
the variable "notable%" and the token for the keyword "not" followed by the
variable "able%". So the old program would still run. But the moment you
convert it to text, then convert it back, you're going to run into problems.
E.g. if you decide you need to change the line:

  dignitary% = notable%(I%): I%+=1

to:

  dignitary% = notable%(I%): I%+=increment%

you are likely to find that the old tokenised form contains the variable
"notable%", but after conversion to text, editing and conversion back, the
new tokenised form contains the token for the keyword "NOT" followed by the
variable "able%". This is likely to cause chaos...

Similar problems would arise e.g. if you wanted to email an old program to
someone: because of email only really handling the normal printable
characters, you would probably send the program in textual form. When the
recipient reconstructs the program, they don't get what you started with...

There are of course other possible ways to ensure the interpreter can sort
out variables from keywords. One such would be to insist the keywords are
always preceded and followed by non-alphabetic characters - inserting spaces
if necessary, and probably not allowing the non-alphabetic character after
the keyword to be "$" or "%". (This is already necessary before keywords -
e.g. the statement "FORi=jTOk" doesn't work, since the interpreter looks for
a variable called "jTOk". To make it work, you need to insert a space to get
"FORi=j TOk" and make the keyword "TO" recognisable.) With this alternative
rule, the interpreter would know that "NOTable%" had to be a variable and
not the same as "NOT able%". You would then be able to have keywords in any
case without too much inconvenience.

However, this change would suffer from at least two disadvantages:

  * It would still cause problems with old programs that had been stored in
    textual form rather than tokenised form (e.g. magazine listings, some
    programs in archives, etc.). (Old programs in tokenised form would
    presumably be converted to text correctly and so could be edited without
    trouble. E.g. the new interpreter would detokenise what had been
    "dignitary% = notable%(I%)" as "dignitary% = notable%(I%)", and what had
    been "dignitary% = NOTable%(I%)" as "dignitary% = not able%(I%)". But it
    wouldn't be able to work with a detokenised program created by an old
    interpreter.

  * For every programmer who had been swearing at the insistence on upper
    case keywords, there would probably be at least one who was now swearing
    at the insistence on spaces where they hadn't been necessary before!

Finally, if you do like the idea of this alternative rule, it would probably
not be too difficult a programming project to write an application that took
a program written in the changed style and converted it to the standard
style. Basically, it would need to recognise keywords in either case and
change them to upper case. Optional extras would be to warn you about
variable names that start with an upper case keyword (which will cause you
problems when the program is subsequently tokenised) and to remove spaces
around keywords that had become unnecessary in the standard style.

One particular keyword you would have to look out for is "TOP". This isn't
in the standard keyword/token tables, since the interpreter actually
tokenises it as the keyword "TO" followed by the letter "P", then has a
special case when interpreting the program to detect this combination.
Keywords that start with other keywords could cause the same sort of parsing
problems as variables that start with keywords: it's fortunate there aren't
many of them!

David Seal
[e-mail]

All opinions are mine only...