gnubol: keyword substitution

[RKRayhawk@aol.com]

In a message dated 1/9/00 4:25:50 PM EST, wmklein@ix.netcom.com writes:

<< 
 All of those are Micro Focus features.  I don't think ANY of them should be a
 high priority for the GNU project, but are certainly things that could be
 considered for a future enhancement. (First, you get current Standard support
 in, then you worry about extensions.)
 
 Bill Klein
   wmklein <at> ix.netcom.com
  >>

Generally most will agree with your prioritization, except that this matter 
of substitute keywords (substitute RESERVE words) has a major impact on the 
design of the lexer and important small impacts on the parser. 

If keywords are hardcoded in flex for example, you will not be able to 
substitute them by external file reserve word lists easily. On the otherhand 
if keywords are tabularized, then we can have alternative spelling mimick or 
replace them. And it would be good to define whether we replace and diable 
the old reserve word, or just set up a parallel keyword.

Interest in internationalization might want to completely substitute the 
keyword list and make all the 'old' reserved words available as user names, 
for example.  Those interested in Trying to coerce INSPECT to do the work of 
EXAMINE, might just want an alias for the verb.

Current work on the bison parser has hard-coded scans for tokens, can that 
survive a reserve word list attachment? The PCCTS tool is sometimes used with 
hard coded text expressions, but I have not studied Mike's latest for this. 
The point is, the reserve word adjunct or replacement feature cannot be 
retrofitted easily.

We are not quite there yet, but diagnostics requires certain conventions that 
might rely on language assumptions. For example, it is _possible_ (no one has 
committed this, but I am saying this illustrates a possible problem) that we 
can hand diagnostics integer %token values, that it will know how to 
translate (by access to the bison genereted header file). That could save 
trafficing in text for keywords.  If the keywords are to be changed 
dynamically, diagnostics may need to know this.

Another design aspect is the scope of keyword substitution. Are we to build 
this for a single invocation of the compiler or down to the program or nested 
program level via control cards.

It may be better to resolve the keyword substitution issue up front.

Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.