Re: gnubol: Re: Magic tokens

[RKRayhawk@aol.com]

In a message dated 12/4/99 9:39:47 PM EST, TIMJOSLING@prodigy.net writes:

<< I would be interested how your parser parses nested
 evaluate/search when both include multiple WHEN clauses.
 
 Once I have the hacks done do some "bet you can't parse this" tests 
(assuming the
 PCCTS grammar is part of a whole executable - is it?).
 
 Tim Josling
  >>

Me too. This is meant in a totally supportive way. The smooth LR tools like 
bison not only tell you about r/r conflicts but they make choices and 
actually construct a table that has made a choice.  If you don't have a 
resolution for the WHEN lookahead challenge by design of rules then only one 
resolution can happen. I am concerned that we may not know there is a problem 
at all in a 'nice' tool like PCCTS. since the first intermediate WHEN that 
causes you trouble may be just one of dozens, how can any modest lookahead or 
backtracking deal with it if it has been described with rules that are 
ambiguous?  I am not against PCCTS nor LLs. I just think it is the advanced 
aspects of the tool that hide problems, COBOL like problems.


All of the tools will be bedevilled by the fact that WHEN OTHER, and 
END_EVALUATE are optional as is END-SEARCH; so we are at epsilon heaven here. 
I think atleast one WHEN is required in a SEARCH (which may help! because 
explication of one prior to recurse will distinguish it perhaps) but actually 
no WHEN is required in an EVALUATE.

And yet another generator of epsilon might be that it may actually be legal 
to code an EVALUATE that has neither WHEN nor WHEN OTHER. Which is code that 
ought to be taken to the shed if it is legal. The WHEN thing could give us 
the best read out on PCCTS as a tool that is or is not alerting us to 
conflicts at an early stage of grammar development.

If in the midst of nested SEARCH/EVALUATE and EVALUATE/SEARCH you can also 
properly nest inline PERFORM and out-of-line PERFORM with it's special scope 
delimiter weirdness; and still get all the feedback you need from PCCTS about 
conflicts it will probably do this language with it. The tool seems too quiet 
to me, but I don't have the experience with it.  My expressions are not a 
condemnation of it.  I really just don't want anyone to invest too much of 
their valuable brain power if the harsh variability of COBOL should prove too 
much for an infinite lookahead tool strapped to k=1 for resource constraint 
reasons.


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