RE: gnubol: Problem 10

["William M. Klein" <wmklein@ix.netcom.com>]

Just for those who are thinking about "knowing" their data division before
they get to the Procedure Division - please do think (in advance) of the
implications of GLOBAL data on a nested program.  I *think* that what you are
talking about will still work with this - but did think I should alert you to
those issues before you go off on a "dead-end" path.

Bill Klein
  wmklein <at> ix.netcom.com

> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of Tim Josling
> Sent: Sunday, December 26, 1999 11:30 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: Problem 10
>
>
> 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.


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