Related articles |
---|
COBOL Parsers mrickan@home.com (Mark Rickan) (2000-04-15) |
Re: COBOL Parsers waratah@zip.com.au (Ken Foskey) (2000-04-16) |
Re: COBOL Parsers vadik@siber.com (Vadim Maslov) (2000-04-16) |
Re: COBOL Parsers eil@kingston.net (John H. Lindsay) (2000-04-17) |
Re: COBOL Parsers tej@melbpc.org.au (Tim Josling) (2000-04-20) |
Re: COBOL Parsers thaneH@softwaresimple.com (2000-04-25) |
From: | Tim Josling <tej@melbpc.org.au> |
Newsgroups: | comp.lang.cobol,comp.compilers |
Date: | 20 Apr 2000 01:36:57 -0400 |
Organization: | Melbourne PC User Group |
References: | 00-04-120 00-04-129 |
Keywords: | Cobol, parse |
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
http://www.geocities.com/timjosling/cobol.html .
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
messages.
Tim Josling
> 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
comp.compilers page.
Search the
comp.compilers archives again.