[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: --no-parser options

From: Hans Aberg
Subject: Re: --no-parser options
Date: Sun, 12 Aug 2007 11:31:06 +0200

On 12 Aug 2007, at 03:13, Joel E. Denny wrote:

Not too long ago (summer 2006 :) we had a long discussion about
dumping the parser tables so that other programs (I wanted to do a
visual grammar debugger) can use them. I even put forward a (possibly
dumb/simplistic) XML representation of the .output file. But there
wasn't any feedback on that. I am not an expert in XML, but if someone
proposes a good schema I can add the required code to Bison.

This is just question of writing a new skeleton file, and the code is
essentially there, though generating in the form C/C++ arrays. But first just strip all macros except what generates those arrays, then make another output
format, if needed.

Currently, generating the .output is more complicated than just printing
out some existing muscles.  Glance through print.c to see what I mean.

Are hinting at that the parser tables are written out in a hardcoded manner? - I noticed that this is a problem with for say the "yy" name- space prefix: Instead of changing it by a macro, some of the names were hard coded.

As for the solution of the problem above, I think that Bison should dump its data in a format that makes it easy to write a greater variety of skeleton files. Perhaps the use Guile instead of M4 might have helped. (The Haskell interpreter Hugs <http://haskell.org/hugs/> I think also has a C interface for foreign data.)

There would remain the problem of being able to write actions that require different parsing than the current, which is adapted to C/C++ syntax. But that can perhaps be changed later down the road. :-)

  Hans Aberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]