[GNU-COBOL] Re: GNUBOL refmod, OFIN and transparencies

[Michael McKernan <mck@tivoli.mv.com>]

RKRayhawk@aol.com wrote:
> 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.
>
 
Without checking the standard, I hope it does indeed read that way.  Shouldn't 
cause us any problems and it's a useful option.

> 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.
> 
See comment below.
> 
> 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, ...
> 
All possible and easily enough done.  The comma delimiter is, like period, 
really comma space, and I believe these can be lexed out as noise. Literals,
of course, are bounded by quotes and recognized by lex as single entities,
and pictures have their own set of problems.

> <<
> 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.
> 
I didn't look.  See below.

> These notes are meant as minor review to the major work you have done.
> 
You overestimate my industriousness.  Most of what you see here is from the
the grammar that Chad and Laura (et al?) wrote a couple of years ago.  They 
used pccts at the time and I think we should use pccts now, so, in the spirit 
of free software :), I'll use their work as a base for my hacks.  As things
progress, I may clean up some things like the ones you mention, but I don't
want to delay reporting things that might be interesting or useful until 
everything is ready for publication.  I'm certain much of this would have been
done, had the authors not chosen to take a different tack.

Incidentally, the one you missed is entirely my fault.  THis rule

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

permits empty parens where the subscripts should be.  Changing '*' to '+'
fixes it and it still parses. 
> 
> 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.