This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A generic reader for Guile?


> > Well, if you're anyway going to rewrite the generator it's probably
> > easier to do it in Scheme.  It's also nice to be independent of bison.

That can always be done later.

> > And note that we *will* have to do a lot of rewriting in the skeleton.

Yup, I have a C++ skeleton that works like bison.simple but for C++
programs. It allows you to run multiple parsers, or a parser within
a parser, whatever. It is missing some of the speed-ups of bison.simple
because I got so confused that I decided to opt for readability over
performance (yeah, sad I know). If anyone wants it, I can email it --
it may help you understand the mechanism of the skeleton, presuming you
read C++ code. It isn't a normal skeleton, you run bison with --no-parser
and put the pieces together again.

> > There's always the risk that we'll be incompatible with the bison
> > generator after a while.  If it's written in Scheme, it will also be
> > easier to maintain.
> 
>    Like I said, I wasn't going to rewrite the generator.  I'm probably
> mistaken on this, but my impression was that all LALR parsers were driven
> by the same tables, so that as long as Bison keeps computing the same type
> of tables, it wouldn't matter too much.  (I haven't really done my reading
> in this area, but I thought it was the fact that these particular kinds of
> tables fully described a pushdown automaton for LALR grammars was what
> made them useful/efficient).

Yup, the table is just token numbers and states. A few points though...
the .y file that is used as input has sections for code as well as
grammer rules, I'm not sure if scheme code will be digested through
that, maybe some place-holder C code can go in and then get scraped
back out on the back end. Also, for scheme nicity the tokens should
be symbols rather than numbers (well it doesn't really matter I guess).

A lot of the outputs are always formatted in C code <shrug> you probably
already know that. More munging to go on the backend.

	- Tel

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]