Re: [GNU-COBOL] COBOL Grammars and Parsers

[Michael McKernan <mck@tivoli.mv.com>]

>>>>> "Chad" == Chad Slaughter <slaught@babba.advancenet.net>
>>>>> wrote the following on Thu, 15 Jul 1999 17:54:08 -0500 (CDT)

  Chad> Michael McKernan wrote :>
  >>  Greetings,

  Chad> Hey,

  >> referring to the rejection of pccts as "inadequate for the needs
  >> of the project".  As I have been, here-to-fore at least, a
  >> non-contributor, I certainly have no right to demand an
  >> explanation, but I do find the decision surprising and I wonder
  >> if anyone would like to enlighten me about the shortcomings of
  >> pccts.

  Chad> sure. The basic problem is one of scale. PCCTS simply could
  Chad> NOT generate a parser for the complete COBOL grammar.  The
  Chad> main problem was it failed on out of memory errors running on
  Chad> 2 separate machines.  machine 1: 4 processor 512MB ram, 4 GB
  Chad> swap machine 2: 4 processor 4 GB ram, 16 GB swap

While the PL/I preprocessor language is a lot smaller than COBOL,
this never became an issue for me on much more modest machinery.

  Chad> I can't remember the lookahead we used, it wasn't that large
  Chad> either.

Ah. That's undoubtedly the reason.  I decided that small k means not
greater than one.  I used syntactic predicate trial parses for
anything that couldn't be resolved with lookahead one and there
actually didn't turn to be overly many cases that needed such
predicates.  I actually felt that the parser was fairly compact.  My
brief experiments with k > 1 resulted in parsers that I considered
unmanageable and a quick glance at your makefile says that you were
using k = 4.  

  Chad> At that point I felt i could do one of two things.  1) Fix
  Chad> pccts.  2) use something else.  I didn't feel like doing
  Chad> number 1, so we went with 2.  I say I , because, at the time,
  Chad> I was the one who would have had to fix PCCTS ( right laura
  Chad> =) but if someone wants to try PCCTS again the grammar is
  Chad> available in the alpha code.  

I really think another alternative is k = 1 with syntactic
predicates as tie-breakers.  I know, I know, I'm welcome to
demonstrate that.

  >> I have also been an implementor on three or six (depending on
  >> how one counts retargetting) commercial COBOL compilers, all of
  >> which used home-grown table driven recursive descent parsers.
  >> My experience

  Chad> We have discussed at length the idea of writing a parser by
  Chad> hand, but don't like the idea.

Nor do I.  It was just a matter of not having the tools available on
certain platforms.  It's no big deal if you have to do it, though.

  Chad> I am very curious of one thing. I would like some in-depth
  Chad> hard technical info about how others have built COBOL
  Chad> compilers. If you have info, please, send it my way and not
  Chad> to the list.

Well, I know some stuff, I guess, but it ain't written down.  I'll
try to decide what's important.  There are only a few COBOL papers in
the literature and they're circa 1962 and pretty hard to find.  

  >> with the preprocessor convinced me that pccts would be a good
  >> choice should I ever have the occasion to parse COBOL
  >> again. This is partly because of the possibility of infinite
  >> lookahead, but primarily

  Chad> In my experience the infinite lookahead, fails in practice.
  Chad> There are other true infinite (ie context dependent) parser
  Chad> generators which do a better job.

Thre may well be.  I stopped looking when I found one that worked.
And of course there is the additional constraint of finding one with
a suitable license.

  Chad> I have nothing against PCCTS per se, just don't think its the
  Chad> right tool for the job. but you are welcome to prove me
  Chad> wrong.

OK.  I'll at least try to find out how many rules break with k = 1.

  >> I hope this hasn't been too irksome for a first post, but I
  >> wanted to
  Chad> no its not that bad. =)

It'll get worse.  I'm really a back end guy and have much stronger
prejudices about other parts of the compiler. :-)






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