RE: [GNU-COBOL] grammar

[David Essex <dessex@aracnet.net>]

At 01:59 PM 25/06/99, Tim Underwood wrote:

>> >tools won't work, as it appears Cobol will require a 
>> LALR(3)/(4) parser, 
>> >at least.  
>> I agree.
>> 
>> From your experience what problems will arise in using bison, 
>> and could you
>> give a concrete example ?
> ...
>After playing around with my own grammars, I just got a "feel" for
>grammars that were easy to parse, and those that weren't.  I remember
>getting many errors using flex/bison, due to ambiguities in the grammar, and
>hence moved to Holub's book and tools.  If I remember correctly, they were a
>LALR(2)/(3), with hints in the book to get to a LALR(4).

I would like to know more about Holub's book and tools(i.e. ISBN, etc). 



> ...
>As I said in the earlier email, our compiler is a hodge-podge (supports VAX,
>ICOBOL, RMCOBOL, ANSI-85, et. al. as well as AcuCobol's extensions to the
>language).
>
>I think a good example would be the ACCEPT statement (as defined in
>AcuCobol's language skeleton).  If you really want, I can duplicate it, but
>Format 1 (of 7) of the ACCEPT statement is a bit over 3 printed pages long
>(with no explanatory verbage).  Briefly, where I see an issue with a
>LALR(1)/(2) grammar is:
>		ACCEPT <dest-item>
>			... omitted ...
>		WITH [NO] ADVANCING
>			... omitted ...
>		WITH [NO] {BELL/BEEP}
>			... omitted ...
>		WITH {BLINKING/BLINK}
>			... omitted ...
>		WITH {CONVERSION/CONVERT}
>		WITH [NO] ECHO
>			{NO ECHO}
>			{SECURE}
>			{OFF}
>			... omitted ...
>
>Ok, the issue isn't what follows the WITH clause, but that these WITH
>clauses are not necessarily positionally dependent within the sentence (at
>least not with the compiler version I am using).  So you cannot properly
>determine the syntax based on where it occurs in the sentence.  So
>yacc/bison will go back a minimum of 2-3 tokens to determine where it is.
>>From my past use of bison (remember, that was 8-10 year old versions), it
>just won't handle this.  

Houston, I think we have a problem. Yacc(bison) will fail where ever the
grammar requires more than one look ahead. 

The number of look ahead in btyacc is infinite, thus it should be able to
parse COBOL grammar.



>If yacc/bison has been improved to a LALR(2)/(3), 
>it might do it, or you MIGHT be able to horse the grammar around 
>to get it to accept it.

I agree. It may be possible to get a work around, but it will not be pretty.



>> 
>> > ...
>> > ... I've also stumbled on btyacc, that sounds like it might 
>> handle the job. 
>> In my experience btyacc is a little unstable.
>
>Loses it's mind?  Stack related?

I did a quick comparison between bison, byacc and btyacc, using the same
input grammar.

Byacc fared the best(not always, usually), with bison in second. The
problem with btyacc seems to be that while byacc and bison will output
errors then stop, btyacc will seg fault and core dump. 

As to specifically why it as a tendency to that, I do not know. At the time
I had no wish to track down the problem.



David


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