gnubol: parser rule naming conventions

[RKRayhawk@aol.com]

In a message dated 12/26/99 11:59:31 PM EST, tej@melbpc.org.au writes:

<< 
 Probably the tk_ is because I am paranoid about namespace
 pollution. I am happy to change to another standard as you
 suggest if noone else objects. 
 
 I also need a standard for productions (like sentence) and would
 like a visible way to distinguigh them from tokens. Any
 suggestions? 
 
 Perhaps
 
 Add : ADD Identifier To_opt Identifier Rounded_opt
 ;
 
 
 Statement:
 Add
 |Subtract
 | ...
 ;
 
 ie tokens in caps, productions first character in caps. There are
 some gray areas like "," and "comma" - what do you call them?
 
 Tim Josling
  >>

I too would look forward to comments around the list.  First off let me 
complement the use of the _opt at the end of names for rules that represent 
optional phrases or keywords. Anywhere there is an /*empty*/ alternative 
should have the _opt on it (I think you are doing it everywhere). It helps 
alot in discussions of epsilons.


For the statement rules like Add or Subtract, I tend to use a naming 
convention that includes the abbreviation stmt_; so stmt_ADD or stmt_add, or 
stmt_Add. My interest being more in the grammaratical structural aspect then 
the verb.  Maybe stmt_ADD would be best. 

For certain kinds of statement groupings I use the abbreviation block_.  I 
sometimes rememeber to put _recur, _recurs, or _recurse on recursive rules.

In the interset of conserving horizontal space I abbreviate words like 
MULTIPLY to MUL, on things where it would be predictable that people would 
know what those are. I do that on the tokens too, so you could get

stmt_MUL : MUL data_ref BY data_ref GIVING data_ref

EVALUATE maybe should be EVAL, again to save horizontal space.

The lexer must look for the real complete value of course.

A concern about namespace pollution is good. Things like PROGRAM, FOR and END 
might cause trouble somewhere down stream (especially if we were going to go 
to Pascal). But in the interest of making the grammar as readable as 
possible, perhaps we can consider some simplifications, and deal with the 
exception namespace conflicts as we encounter them. The number of places we 
would have to make mass changes with the editor should be limitted.

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.