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

[Robert Sherry]

Keisuke,

     If I was writing the parser for a COBOL compiler I would use the power
of YACC to parse the expressions. I feel this approach is easiest to
implement (YACC does the work) and the grammar reflects the language being
parsed. Below is a YACC file that shows a simple expression parser for
COBOL.
 
Bob Sherry

%term IDENTIFIER
%term INTEGER
%term STRING_LITERAL

/* Here are the key words */
%term COMPUTE

/* Operators */
%term ASSIGN_OP
%term POWER_OP
%term PLUS_OP
%term MINUS_OP
%term MULT_OP
%term DIV_OP
%term LEFT_PAREN
%term RIGHT_PAREN
%term COMMA

/* Puncuation marks */
%term PERIOD
%%
program: statementList
program: statementList
        ;

statementList: statementList statement
        |
        ;

statement: assignmentStatement
        ;


assignmentStatement: COMPUTE identifier ASSIGN_OP pow_expression PERIOD
        ;

pow_expression: expression POWER_OP pow_expression
        | expression
        ;

expression: expression PLUS_OP term
        | expression MINUS_OP term
        | term
        | PLUS_OP term
        | MINUS_OP term
        ;

term: term MULT_OP factor
        | term DIV_OP factor
        | factor
        ;

factor: identifier
        | INTEGER
        | LEFT_PAREN expression RIGHT_PAREN
        ;

identifier: IDENTIFIER
       ;


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Keisuke
Nishida
Sent: Wednesday, April 20, 2005 2:11 PM
To: Robert Sherry
Cc: address@hidden
Subject: Re: [open-cobol-list] New to the Compiler

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


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list