[open-cobol-list] Re: New to compiler

[Roger While]

Adding on to what Keisuke said -
Firstly quoting from the Bison manual -
".. but most real grammars have harmless shift/reduce conflicts
which are resolved in a predictable way and would be difficult to
eliminate." Section 3.7.7
COBOL is tricky in that -
a) A lot of syntax/words are optional.
b) Words are overloaded

In particular, as Keisuke pointed out, "NOT" is a problem.
Normally the parser has only one token of look-ahead.
(LR/LALR). I tried converting the parser to GLR but gave up.

I came across a program in the cobol85 tests that would not
compile which also has a "NOT" problem. Consider -
CALL ...
  ON EXCEPTION
    ......
   ADD id1 TO id2
     ON SIZE ERROR
  NOT ON EXCEPTION
   .....
[END-CALL]

In current release/CVS as soon as we hit the
NOT ON we think this is the phrase for the ADD
and get the error "unexpected EXCEPTION".

In a forthcoming CVS update, I will have fixed this
by "tokenizing" several expressions like
[NOT] [ON] EXCEPTION/SIZE ERROR/OVERFLOW
/EOP/END_OF_PAGE/INVALID KEY/INVALID.
In other words, I have moved these into the scanner
and produce unique tokens for the parser.
I believe we can use this technique to resolve the
EVALUATE problem.
Without having looked at it, we probably could
tokenize "EVALUATE TRUE/FALSE" and
"WHEN NOT" to get around this problem.

Roger

>Keisuke Knishida wrote:
>>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