Re: [GNU-COBOL] GNU-COBOL list reborn

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

>>>>> "Tim" == Tim Josling <tej@melbpc.org.au>

  Tim> Michael, I am playing around with BTYACC and I intend to start
  Tim> heavy duty trial parsing of various test cases this
  Tim> weekend. Could we work together on some test cases to exercise
  Tim> the parser generators?

Sure, that would be great.  I suspect that you work harder than I do.
I am convinced, though,  that the right thing to do is return to
pccts, which is the most flexible parser generator I've ever seen.  I
sent a set of patches to the list some months ago for the original
grammar, that enabled it to generate an LL/1 parser with selective
lookahead.  It's probably still in the archives if you're interested,
or I could mail it to you.  That grammar would still need a lot of
work, but I think I've been able to show that pccts is up to the task.

  Tim> Here is an example:

  Tim> move a to b (2 * c + d) (1:2).  move a to b (2:3).
  Tim> .............^

  Tim> At the point of the "^" there is an ambiguity whether you are
  Tim> looking at a reference modification or an array reference.

  Tim> As far as I can tell, no finite amount of lookahead can get
  Tim> past this problem, just based on syntactic processing (of
  Tim> course there is the standard 'typedef' hack that can help with
  Tim> this (see the Bison manual for details) - but this gets ugly
  Tim> fast.

I'll try to add that to the old grammar this weekend and I'll let you
know how it comes out.  I'm quite certain it can be handled (I've
done it in the past) but let's see if we have to push the tool to get
it done.

  Tim> Any other hard cases would be great as well.

  Tim> On the runtime side, I think it would be good for people to
  Tim> start work on that. Ther is a lot of work there.

  Tim> I suggest

  Tim> 1) Suggest an interface to the runtime to the team (for each
  Tim> of the many runtime things - sort, file handling, merge,
  Tim> report writer).

For runtimes in those categories, I tend to agree, although report
writer is pretty broad interface.

  Tim> 2) Assuming people on the parser side agree, do it.

  Tim> My approach at the moment is to get something that works,
  Tim> focusing on the nucleus level 1 and on up first. Worry about
  Tim> performance later. The simplest thing that can possibly work.

I doubt that the performance of the parser will be an issue, Tim, but
it's worth taking some time to get trees or whatever it is we're
going to use, that can be processed easily in subsequent phases.

  Tim> Tim Josling

  Tim> Michael McKernan wrote:
  >> ...  Looks like it might be Time for me to climb down from the
  >> soapbox and do some work around here, so unless Tim is
  >> determined to do it, I'll (shudder) commit to doing the parser.
  >> 
  >> Mike


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




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