End and the syntax parser

[Brian K. White]

Come on are you guys thinking?
You can't make reserved words actually an error. There are too many of 
them and too much code already written and new "reserved" words map pop 
into existence at any time. And you can't pick some to be errors and 
others not. All you can do is go by the actual rules of the language and 
detect actual unambiguous errors, not try to find things that "look" 
like errors or that don't conform to any ideas of best practices.

right off the bat, you're going to throw away some of the few dummy 
variables that happen to be eq lt gt etc...?
Sure a line like "If: eq gt ge" requires a careful look to read, but you 
can't disallow it. Even if you were willing to find every "eq" in your 
code, forms, screens, browse formats, selection sets all through your 
system, how to you fix when "eq" isn't just a stand alone dummy but a 
member of a consecutive dim() mapping? Now you have to throw out the 
whole associated consecutive set and shift them all up or down so that 
the list fits in between any "reserved" words, displacing your existing 
use of all those other dummies, or maybe fp now just skips over those 
disallowed dummies, so if you have a consecutive list from ea to fi , 
under the new system the same dim line would create ea to ep and er to 
fj instead, and all the dummies from er to fi would be off by one from 
what your code expected, and fj would just be new.

This is just one tiny example. You can't reserve every meaningful word.
There is no problem that needs fixing here. As a programmer, you simply 
have to know what to do and what not to do.


As for junk-after-end,

I would say that any non-space on a single line that comes after an end 
statement, on the Then: part of a line, but before a semicolon or single 
qoute could be flagged as a warning in syntax check.

It has to really only detect an unadorned unambiguous end statement 
though, not things that look like end statements due to too-simple rules.

You have to allow variables and labels that not only begin with end, but 
are just plain end itself. I want to be able to say "goto end"
and "screen end", "popup update end", "write end", etc. "gosub end" 
would be a bit misleading, but even that is my business. Maybe it used 
to really end and later developments meant that routine now needs to be 
a gosub? Or maybe end stands for Evaluate Next Destinataion? It's not 
fp's or anyone elses place to say I can't do that.
You also have to allow dropping an end statement at the beginning or 
anywhere in an existing line.
ie:
You should be able to have an existing line of code:
Then: some stuff ; some more ; yet more
and be allowed to disable all or part of that line, without requiring 
you to copy and comment it all by doing
Then: <step 1> ; end ; <step 2> ; <step 3>


-- 
bkw