[GNU-COBOL] GNUBOL refmod, OFIN and transparencies

[RKRayhawk@aol.com]

In a message dated 10/30/99 9:38:35 AM EST, 
Michael McKernan mck@tivoli.mv.com writes the following production rule:

<< 

 refmod
    : OPAREN integer COLON integer CPAREN
    ;

 >>

A minor note. Let me re-express this for clarity ...


 refmod
    : OPAREN integer1 COLON integer2 CPAREN
    ;


integer2 is not required on compilers I have used.  The compiler in that case 
will understand that the programmer refers to the portion of the data item 
starting at position integer1 and going to the end of the data item.  The 
compiler then does the work of calculating the length for us.

This relaxed syntax is not only permitted but often recommended, as being 
more maintainable.  

I do not know if the standard reads that way.

Also, once upon a time it was legal to have within a single program  
paragraphs with identical names in different SECTIONS.  To PERFORM a 
paragraph like that required syntax such as PERFORM AMBI-GRAPH OF 
SECT-WHICHEVER. Does this still apply in COBOL-85? Do we want any kind of 
backward compatibility to such code? And have you tried to add a rule to 
support such syntax into the same grammar that contains your 'qualifier' rule 
for dataname references, which was:

<<
qualifier
    : ( OF | IN ) ident 
    ;

>>


If this ambiguous paragraph name issue applies
 then we may want distinct 'ident', 'PROG_NAME' and 'qualifier' for datanames 
as opposed to procedure names. But still the OF/IN token could be a source of 
ambiguity. Let's ferret it out as early as possible in our work.


As an aside, I would recommend generally that we turn the OF|IN distinction 
into a transparency to reduce parser internal table size. That is, if the 
lexer sees OF, it returns OFIN, if it sees IN it returns OFIN. A similar 
recommendation seems appropriate for IS|ARE and a few other wonderments like 
ZERO, ZEROES and ZEROS, as well as PIC|PICTURE.

Is there anyone out there who is qualified to compose a complete list of such 
transparent token groups?

More radically, COMMA should probably be invisible to the procedure division 
parser (they are needed in literals). That almost applies to the data 
division, but you would have to make it context sensitive for PIC clauses and 
literals. I am not actually straying off the subject here. The 'subscript(s)' 
productions, ...

<<
subscripts
    : OPAREN (subscript)* CPAREN
    ;

subscript
    : (ident ( qualifier )* { (PLUS|MINUS) integer } | integer) 
>>

will need to handle _optional_ commas. 

And one further note, a question really.  Do you define 'integer' as positive 
or unsigned? It cannot be unary negative.

These notes are meant as minor review to the major work you have done.


Best WIshes,

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