Re: gnubol: [rpragana@acm.org: Some comments about a cobol parser]

[Tim Josling <TIMJOSLING@prodigy.net>]

RKRayhawk@aol.com wrote:

>
> Permit a suggested terminology. We could have positive logic rules
> (productions) and error productions.
> Error recovery is sometimes used to refer to the engagement of mechanisms
> built into the code generated by the parser tool.
> I suggest that restricted use of the word.

OK - good idea.

>  IF cond THEN stmt_block ELSE stmt_block END-IF.
>     { life is fine };
> It would not be too surprising if we saw someone code an error production to
> trap excessive END-IFs
>   IF cond THEN stmt_block ELSE stmt_block END-IF  END-IF.
>     { life is not so fine, extra END-IF ignored (call it unbalanced) }

I am amenable to suggestions on this; these things can be very useful. The
classic example is in GCC where they flag the perfectly valid statement

if (a=b) xxx;

with a diagnostic

"probably that assignment should actually be an equality test"

It probably should be

if (a==b) xxx;

You can avoid the diagnostic by coding extra parentheses:

if ((a==b)) xxx;

if you really want that.

This though tends to create a huge number of shift reduce and reduce/reduce
conflicts and it is very tricky to make sure the right rule fires all the time. I
don't know any solution to this.

I just completed the conditional expression grammar, and I had a lot of trouble
getting a clean run through bison with no SR or RR conflicts. I am very wary of
adding anything to this delicate structure. Adding productions including 'error'

My objective at the moment is to do error productions to ensure we don't miss too
many errors.. We don't want to say

pr_verb error tk_fullstop

as an error recovery as we may lose too much stuff, and the programmer may have
to do extra compiles to find the errors hidden by the first error.

so I would want to do:

pr_verb error pr_end_statement_marker

So at least you start parsing again at the next verb. This would produce spurious
errors such as

if a < > b then
   display
else
>> why is this else here, I don't recall an if, because my error production was
incomplete.
  display.

Programmers are probably fairly used to this though.

Actually this may be a bad example. Conditions tend to go wrong often, so it may
be worth delimiting the condition, and it's not that hard because you have either
a verb, 'then', or a period next. Then the error production could be:

if error end-condition [then]
  imperative_statement
[else imperative_statement]
[end_if]

As previously discussed, there is probably a need for two productions for most
verbs, a conditional version and an imperative version, so it is actually a lot
more complex than that.

You are suggesting a higher level of error productions where you repair bad code.
One thing I have seen compilers do is fix up missing periods at the end of
paragraphs. There was some discussion of this earlier on. If you are doing free
format basically this is not difficult..

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.