Re: gnubol: keyword substitution

[Tim Josling <tej@melbpc.org.au>]

The bison parser uses a keyword table, mainly with a view to
controlling which keywords are recognized as keywords for a given
option (eg do you want 'goback' and the other IBM extensions). At
present I use gperf to generate a lookup function for the
keywords - this implies a static set of possible keywords and no
dynamic substitutions.

I don't see any problem adding these goodies later. It would be a
problem if the flex definitions had all the keywords hard coded
in them, but they are just a lookup, and you can build the lookup
how you like. The scanning uses the token IDs, not the literal
values.

Tim Josling

RKRayhawk@aol.com wrote:
> 
> 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.



--
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.