Re: gnubol: [rpragana@acm.org: Some comments about a cobol parser]

[Tim Josling <TIMJOSLING@prodigy.net>]

I think this approach may be valid - I am trying it out approach as we speak. I
have gotten through to the evaluate verb in the procedure division (in
alphabetical order). I have so far about 6 hacks I need to put in to avoid a
backtracking or Lx(n>1) parser generator. I will publish once I get through the
whole procedure division (nucleus level 2 plus IPC level 1).

I used this approach to get past the uncertainty about nested statements. The
prescanner needs to keep a stack of current verbs. I have found no showstoppers
so far. One thing this does to you is that it makes it hard to do good error
messages, but you have the same problem in spades with backtracking.

So it is a little more difficult that implied below. How much more difficult I
should know by the end of thanksgiving, given the present rate of progress.

My test parser just parses. No error production, though I have an idea how to do
good enough error recovery..

Tim Josling

> But suppose we separate our parsing in phases, such that all variables,
> declared at the data division, could be detected and separate tokens are
> given by the scanner (say VARIABLE and LABEL) when an identifier is
> found.  We already know (at the procedure division) what is VARIABLE. As
> all variables are declared in advance, the scanner could make everything
> LABEL if not found at the symbol table, so there is no need to
> backtrack in such constructs anymore.  Why this is interesting? Because in
> this case, we can use a proven tool like yacc/bison to make our parser and
> it should be much more faster and error prone.
>
> Rildo
> rpragana@acm.org


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.