Re: gnubol: Problem 10

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

RKRayhawk@aol.com wrote:
> ...
> 
> If the data division is parsed completely first, then
> the lexer (or a filter) can manifest a generic name as a data_name
> or procedure_name (or atleast not_data_name), so where is
> the ambiguity?  In the two perform format groups?
> 

In effect this is what I do, but not in the suggested manner. You
are suggesting I change the identifier token or group of tokens
rather than the PERFORM token.

I will think about this. My reasons from memory were that I was
not happy the symbol table was incomplete so I wanted to have the
syntax do as much work as it could because there may be cases
where a data name and a procedure name coincide. But I have not
thought it through fully.

> ...
> the optional WITH TEST BEFORE |
> AFTER should not be buried down inside of the optional UNTIL clause.

It probably just evolved that way. I vaguely remember a problem
with a RR conflict.

> In such competitive pairs it is the one with the %prec
> PREC_YIELD_TO_something that carries the warning message about scope
> termination.  This is easiest in the inline perform.
> 
> You need that much sophistication to deal with coding errors where
> END-PERFORM is left out.  Implicit scope termination of inline perform is
> simple. It is the illuminating case.
> 

This may be a good idea. I have added a note to the grammar to
try this out.

> --------
> Now on the other-hand trapping erroneous END-PERFORM where they do _not_
> belong is not so easy. ... But if I am not mistaken, I
> saw at least one post that claimed a current product actually allows
> END-PERFORM on perform procedure name format statements: which raises a
> miniature codebase issue.


They must have an algorithm something like:

if I find an end-perform, and it doesn't belong to any perform
that should have it or it could belong to one and he already has
an end-perform, then try and pair it to a perform that should not
have an end-perform! Or is there a simpler way?

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