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 7 Jul 1999, Mikael Djurfeldt wrote:
> Lynn Winebarger <owinebar@free-expression.org> writes:
> 
> >    Uh, why didn't you try looking at the source?  doesn't flex have an
> > explicit skeleton?  (I know Bison does).
> 
> I did.  It has.  I needed some guidance from the output since I didn't
> want to study all of flex's source before getting this hack running.
> 
   I can certainly concede that point.

> >     What do you mean by a "Scheme spec"?
> 
> The rules/grammar in Scheme syntax.

   What does that mean - as far as I know, there's no universal way of 
writing a syntax in scheme.  

> If the port of the scanner skeleton is made well, all state
> information will be incorporated into the scanner type and scanner
> objects so that scanners of different types can run in parallel.
> 
   Sure.

> >     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.
> 
> Yes, or write it in Scheme.
> 
> >    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.
> 
> 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.
> And note that we *will* have to do a lot of rewriting in the skeleton.
> 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).

> >    I could work on it, but I'd need some kind of guile user's manual to
> > see how it's supposed to work.
> 
> That would be great!
> 
> What do you mean with manual?  There's the guile-ref package.  Is that
> enough?
> 
   It wasn't available via the web site download when I grabbed the source
for 1.3.  But now I see guile-doc is part of the snapshots, so I grabbed
it.
   I think it would be useful to have at least a pointer to some docs on
the peculiarities of guile on the web page, even if they aren't finished
or, alternatively, out of date.

> I'll pack together what I have tomorrow and write down a few notes on
> how it's supposed to work.  Then I'll mail it to you.
> 
   I'll take a stab at it eventually, as long as I'm playing around with
Bison parsers anyway.

Lynn



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