|COBOL Parsers firstname.lastname@example.org (Mark Rickan) (2000-04-15)|
|Re: COBOL Parsers email@example.com (Ken Foskey) (2000-04-16)|
|Re: COBOL Parsers firstname.lastname@example.org (Vadim Maslov) (2000-04-16)|
|Re: COBOL Parsers email@example.com (John H. Lindsay) (2000-04-17)|
|Re: COBOL Parsers firstname.lastname@example.org (Tim Josling) (2000-04-20)|
|Re: COBOL Parsers thaneH@softwaresimple.com (2000-04-25)|
|From:||Tim Josling <email@example.com>|
|Date:||20 Apr 2000 01:36:57 -0400|
|Organization:||Melbourne PC User Group|
Vadim is quite correct. To parse the Cobol 85 nucleus alone, I had to
put many hacks into my code to help the standard tools along.
You can have a look at the details in my pre-pre-alpha Cobol compiler
if you are interested at
The file that has the description of the hacks is
gcc/cobol/cobctok.def. The grammar is in the same directory cobcprs.y
Similar problems exist in other parts of the language. It is not
actually rocket science but it does make it hard to provide good error
> In fact, grammar of Cobol is fairly tricky at times.
> Example: Cobol grammar is non LALR(1), that is it requires lookaheads
> of more than one.
> Example: to distinguish between 2 forms of PERFORM statement
> PERFORM A OF B TIMES COMPUTE X=Y+Z END-PERFORM and
> PERFORM A OF B COMPUTE X=Y+Z
> we need a lookahead of 4 tokens.
Return to the
Search the comp.compilers archives again.