Re: gnubol: Re: which parser tool

[Tim E Josling <TIMJOSLING@prodigy.net>]

RKRayhawk@aol.com wrote:

> As some previous interaction has brought out, we can go after just valid
> programs or try to go after a larger class that includes likely errors and
> errors that would cause trouble if we don't aggress them.

I don't really grok what you are saying about putting more into the parser.  I
would see some simple error productions only. The challenge with cobol is to
avoid throwing too much away. Waiting for a period is too long. Any good ideas to
help with this are welcome.

> My general notion is to reduce any such
>   c of d of e of f
> as a basically a rule unto itself, and naturally include its symbol name in
> rules for the IF and MOVE.

Yes I think that is a good idea. And I decorate it with the type info.

>  You mention a
> count of a hundred lines to deal with part of this issue in the preprocessor.

That's lines of C.

>  But I am already thinking there is something like an AST that
> can be decorated with error flags that commute up (if that is proper
> terminology).

Good idea, we do as much checking as we can.

> Do you see from these generalizations how this potentially allows the higher
> level rules to stay on their feet? The fact that errors were detected must
> live on.

Yes I think that is sound.

>
> I am strongly convinced that we can not allow something like an IF or MOVE to
> stop parsing if it is at all close to right.

This is one reason not to put too much into the parser. The parser should
recognise things, fairly liberally. Then we check it. The trouble is the more you
put into the parser the more it is likely to throw away.

> By the way care to guess about total parser rule count before its done?

I know that the number of states exceeded the 16 bit integer so it is a large
number. I probably don't want to know.

> But moreover, what we really need is a design of the interface to semantics.

Can you expand on this for me. Give examples.

Regards,
Tim Josling




--
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.