|
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 avisual grammar debugger) can use them. I even put forward a (possiblydumb/simplistic) XML representation of the .output file. But therewasn't any feedback on that. I am not an expert in XML, but if someoneproposes a good schema I can add the required code to Bison.This is just question of writing a new skeleton file, and the code isessentially there, though generating in the form C/C++ arrays. But first just strip all macros except what generates those arrays, then make another outputformat, if needed.Currently, generating the .output is more complicated than just printingout 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
[Prev in Thread] | Current Thread | [Next in Thread] |