Re: COBOL Parsers

Tim Josling <tej@melbpc.org.au>
20 Apr 2000 01:36:57 -0400

          From comp.compilers

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)
| List of all articles for this month |
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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.