Re: gnubol: New bison Grammar available (long)

[Tim Josling <tej@melbpc.org.au>]

RKRayhawk@aol.com wrote:

> <<
> They (all the nucleus grammar in fact) would be parsed but you
> would get an error message 'not supported in the core subset used
> to build the compiler'.
> >>

It will fullly parse it. The error message will be produced by
the the production.

I agree about proving the parse works. Testing this is nto too
hard with bison because you can do a parser trace and it will
tell you all the steps. That'y why the 'parser-trace' option is
in cobgocmp.c.

> The following is not intended to harp on a point, or to make anything out of
> it more than the technical interaction already posted about the shift/reduce
> conflict on the ELSE clauses.

Bob can you suggest some test cases and I will run them as a
priority.

> Concerning the nesting of EVALUATES and SEARCHES, I would offer this
> expression to you: really, honestly, and sincerely, ... we need to get all of
> it to nest before we deploy any cardinal verb.

The problem is with evaluate and search I don't actually know how
to do it because some of the clauses are almost valid in the
other verb, but not quite - and this can depend on the symbol
table.

> 
> The reason this is urgent is that you may find your tool does not work, or
> that your strategy does not work. That will create much extra work later if
> you need to really modify the strategy, or even choose another tool.  For
> example, if bison can not resolve the ambiguities, and PCCTS with predicate
> assisted back tracking can, what will have happened to you the coder of the
> bison effort?
> 

I will be very grateful that I cleanly separated the parser from
the rest :-). Still it will be a lot of work. I suspect a pccts
grammar would be a lot shorter though. 

Maybe better tools will be around then.

We do differ on the merits of Big Design Up Front as we know. I
agree with Kent Beck - "You ain't gonna need it". So much will be
different in a few years it is hard to plan for. When I go back
to the wav2midi program I need to decide how fast a CPU to target
- it really is difficult to anticipate the future.

There have been at least 5 free cobol grammars done that I am
aware of. No doubt there will be more in the future. 

> If we hope to
> consider transposing conditionals, or consider it our responsibility to
> choose a tool and a strategy that permits transposition for the future GNU
> COBOL contributors who will migrate the tool to COBOL-2000, then I am sure
> bison can not take us to the finished line, IF WE USE OPTIMISTIC HIERARCHIES.

In my tests of transposing the conditionals I found no problems
at all. Not even any more SR conflicts. I have a vague feeling
that allowing transposed conditionals may actually change the
meaning of existing programs that had nested conditionals, but I
have not been able to generate a case where this actually
happens. 

Still if people use non-standard extensions they are taking a
risk that a new standard will break their code. In any case I can
put in a warning of possible incompatibility along the lines of
the warnings required in cd1.7.

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.