Re: gnubol: Re: which parser tool

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

Michael McKernan wrote:
> 
> >>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
> >>>>> wrote the following on Fri, 12 Nov 1999 14:09:27 EST
> 
>   Bob> On Date 10/31/99 1:51:52 PM EST Michael McKernan,
>   Bob> mck@tivoli.mv.com writes
> 
>   Bob> in part << Pccts is the exception, .... It _does_ have
>   Bob> infinite look-ahead. That sounds expensive, but it's only used
>   Bob> when it's required so as a practical matter, it isn't a
>   Bob> problem
>   >>>

Well actually PCCTS has finite lookahead in any given parser that you
generate. But it also has backtracking which has more or less the same
effect as infinite lookahead.

>   Bob> This is not intended to pick on any one person or a particular
>   Bob> phrase; there are numerous posts in the project with phrases
>   Bob> similar to Michael's, to the effect " ... it's only used when
>   Bob> it's required ... ". What may not be clear to some of you is
>   Bob> that you are using it very, very frequently. I think I did not
>   Bob> use enough very's in that statement.
> 

We are in need of some evidence in this case. I think backtracking would
not be a problem in COBOL because it is not needed often but my opinion
is worth as much as anyone's without evidence.

> Your own suggestion of classifying identifiers (which has merit --
> there are admittedly difficulties doing the same thing in a
> predictive parser) might have met with more resistance ...
> 
The prerocessor uses identifier classification with a few hundred lines
of code. I think you will need something like this regardless of parser
tool for the "if a and not b and c of d of e of f" case.

>   Bob> Every such actual program statement MOVE simple-name-1 TO
>   Bob> simple-name-2.  engages the thing you all are thinking is
>   Bob> free, engages it twice.  (some VARYING clauses thrice, more
>   Bob> for arithmetic statements that have lists of data references).
> 
 move a (
The ( could start an array reference or a reference modification. So
this will generate backtracking for the wrong choice (wrong one of two).

How serious an issue it is remains to be seen - we need some data.
Normally the parser is not the slowest part of a compiler, so even
doubling the cycles in the parser should not be a show-stopper. Perhaps
in some cases there could be an exponential explosion. 

At present the only case for backtracking I have run across is the
reference modification/array ambiguity. I don't see that forcing an
explosion. Refmods are only allowed in certain circumstances so you
could use a less powerful form of identifier in most cases that
eliminates the suspense.

Tim Josling



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