Re: gnubol: Re: Cost of Backtracking

[RKRayhawk@aol.com]

There has been discussion of how much error processing to code for in the 
parer(s).

In a message dated 11/15/99 11:09:51 PM EST, 
Tim Josling,tej@melbpc.org.au writes:

<< 
 I am not convinced on the need for elaborate error handling. I don't see
 it in compilers I have used and as you point out so eloquently, it
 causes a lot of grief. In a backtracking compiler you get an exponential
 explosion. In an LALR(1) compiler, you get lots of conflicts.
 >>

So you have capsulized it.  I do not mean to put words in your post; but 
there it is as I understand the consideration.  We think is either LL or LR. 
That is, possibly, a false choice. We get to that fork in the road because we 
are all sane and we say we will not go down the road of hand coding a 
lexer/parser.  I say that if we design, if we produce design documents, and 
if we consider it judiciously, then the design requirements portrayed do not 
say pick LL or pick LR.

You can catch sight of the _kind_ of problem we have if you just look at the 
generally accepted idea that it is a bit of a problem that the parser tools 
are not reducing by type. Type has to be either toted as member elements in 
our structures or we have to do the untinkable of trying to emulate 
attributed grammar methodology with dangerous references to things in 
$-n. This is a _kind_ of insufficiency in many of the tools.  I am not 
focusing on type as the issue. I am saying that things like type, 
associativity and more are very unique in COBOL.  It is not necessarily the 
case that any of the available tools are going to do this parsing for us.  

But depending upon what error processing is agreed upon, and depending upon 
the design of the syntax to semantics interface: big implications arise per 
the applicability of LL or LR.

Doing the semantics is the hardest part. Please do not interpret the 
following statement as minimizing semantics or belittling the extremely 
valuable contribution that the coders of the semantics will be working so 
hard on.  But in the parser, ...  really want to go out of my way to be both 
clear and to avoid any possible offense to those with interest and aptitude 
in the semantics areas ... , so _in_the_parser_ semantics are of minimum 
concern. And naturally that is IMHO.

If gnubol does not have elaborate error handling, I think it will be little 
used. However this is not just a question of placating projected users of 
this thing. Whatever the error handling strategy, it must be designed first, 
then we code. It is a question of treating the coder with respect.

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.