Re: [open-cobol-list] New to the Compiler

[Keisuke Nishida]

Robert Sherry wrote:
>         I was looking at the file parser.y. I noticed that when the file was
> run through YACC, there were numerous shift/reduce conflicts. I was
> wondering, if anybody has made any attempt to eliminate some of these
> conflicts.

Currently, there are 86 conflicts in parser.y.  In the past,
there were more than 700 conflicts in the same file.  I tried
to eliminate all of them, but it was not trivial to solve the
remaining ones.

> I also noticed that the grammar for expressions in COBOL was
> basically a list of tokens rather then the more traditional grammar for an
> expression. It seems to me that doing it this way was more work for the
> implementer. Is there a reason it was done like this?

parser.y actually reads tokens sequencially, pushing them into
a hand-written shift/reduce parser for COBOL expressions.
See the definition of `expr' in parser.y.  Do you have any idea
how this could be done in a better way?

There are some problems in the current implementation, though.
There are 3 shift/reduce conflicts in `evaluate_object', where
it is not very clear whether the word "NOT" is part of the
EVALUATE statement or not.  Consider the following examples:

Case 1)

 EVALUATE X
 WHEN NOT Y
   ...
 END-EVALUATE

In this code, "NOT" is part of the EVALUATE statement, and the
condition is evaluated as "NOT (X = Y)".

Case 2)

 EVALUATE TRUE
 WHEN NOT X = Y
   ...
 END-EVALUATE

In this code, "NOT" is part of the expression, and the condition
should be evaluated as "(NOT X = Y)".  However, the current parser
reads this as "NOT (X = Y)", which is not a big problem but not
correct.

Case 3)

 EVALUATE TRUE
 WHEN NOT X = Y OR Z = 0
   ...
 END-EVALUATE

The parser should read this code as "(NOT X = Y) OR (Z = 0)".
Currently, it does as "NOT (X = Y OR Z = 0)", which is absolutely
not correct.

In order to fix this problem, we need to somehow modify the
expression reader and parser.

Keisuke