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?


On Wed, 7 Jul 1999, Mikael Djurfeldt wrote:
> Here's what I did:
> 
> I ran flex for a simple specification file.  From this output I
> deduced what was fixed code from a template and what was variable
> (dependent upon the specification file).  It turned out that
> everything that was variable consisted either of C preprocessor
> macro definitions or tables of numbers.

   Uh, why didn't you try looking at the source?  doesn't flex have an
explicit skeleton?  (I know Bison does).

> So I thought: Why not turn the macros into variables and write Scheme
> level accessors for them, and turn the tables into uniform vectors?
> Then it is possible to install the tables from the Scheme level.
> 
> Look what we have!  Ta ta!
> 
> An extremely efficient, dynamically configurable generic lexer!
> 
> In order to generate proper numbers for the tables I wrote a Scheme
> program which converted a Scheme spec into a suitable flex input file,
> ran flex and extracted the numbers from the flex output.
> 
    What do you mean by a "Scheme spec"?

> Now, *this* was a hack, but I think the idea of a dynamically
> configurable table-based parser is great: you write the time critical
> inner loops in C and crunch the rules from the grammar into tables.

   dynamically configurable?  I'm not sure what you mean by that - the
tables are pretty fixed by the grammar specification.  Of course, you
could replace the actions dynamically.

> Wouldn't YOU, dear reader, find it just great to spend your summer
> holiday reading the table-based parser section in Aho's dragon book,
> studying the tricks used in flex and bison to achieve optimum
> performance and implement this idea?  :-)
> 
> It may even be possible to port the template code directly from
> flex/bison and port the C code for generating the tables to Scheme.
> 
    Actually, I spent my spring break reading Bison, and it was no picnic.
That code is crufty.  The parser skeleton isn't so bad.  But I would not
suggest translating Bison directly into Scheme.  Better to write your own
generator, and wrap the Bison parser in a scheme function.
    I did fiddle with the parser skeleton to make it use some dynamic
function calls and use tables defined at run-time instead of compile time.
This was so I could use it in an object oriented way in a multithreaded
program.  (this was only the bison.simple, not the bison.hairy)

   Anyway, I would also be interested in this, though I see no real need
to port it to Scheme.  Bison can output just the tables if you want, and
you could call the parser through scheme.
   I could work on it, but I'd need some kind of guile user's manual to
see how it's supposed to work.

Lynn



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