RE: [GNU-COBOL] grammar

[Tim Underwood <TimU@hightouchinc.com>]

> -----Original Message-----
> From: David Essex [mailto:dessex@aracnet.net]
> Sent: Friday, June 25, 1999 12:22 PM
> To: gnu-cobol
> Cc: Tim Underwood
> Subject: Re: [GNU-COBOL] grammar
> 
> 
> 
> On 24/06/99, Tim Underwood wrote:
> 
> > ...
> > ... what "yacc" tool are you using?  I'm sure the standard 
> bison, etc. 
> >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 ?

Ok, first off, my experience is EXCEEDINGLY rusty.  I haven't used lex/yacc
(flex/bison) for about 8 years.  So my assumptions are somewhat based on a
"gut feel".  I had really used these tools years ago, and had created
several pseudo "natural language" (heavy on the pseudo) configuration file
parsers for programs.  Basically developing my own grammar(s) for these
tools.  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).

Until I got a new job here about 3 months ago, I haven't used Cobol for
23-24 years.  (I'm not THAT old, I just started coding when I was 14).  I
had forgotten how ambiguous Cobol can be.

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

The problem I have is that I am trying to bring in some documentation and
determination tools into play, on the cheap.  I have a tool that will accept
a type of pseudo-code, and will create a flowchart.  I would dearly love to
do this, as it would help decipher some code that
I have never laid eyes on, as well as help to do some complexity/redudancy
checks on the code.  The source extends over a 20 year period (what Cobol
code doesn't), so it shows the evolution of the language/compiler.

Originally, there were no END-IF, END-ACCEPT, etc. statements to end a
"sentence block", just a period, now we have these features and dozens of
others, so a piece of source that is 20 years old has almost every
conceivable construct found in it, relating to the  compiler/language
ability at the time.

So, while it may be possible to do an ANSI Cobol grammar with bison, I don't
think that it will help me in any way with the kind of grammar constructs
that our compiler allows.

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

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

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