Re: A generic reader for Guile?

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

Lynn Winebarger <owinebar@free-expression.org> writes:

> > >     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.  

I was referring to the metasyntactical style of the specification.

Instead of writing

     ...
     exp:      NUM                { $$ = $1;         }
             | exp '+' exp        { $$ = $1 + $3;    }
     ;
     ...

you write

     ...
     (exp ((NUM)         (lambda (x) x))
          ((exp #\+ exp) (lambda (x y) (+ x y))))
     ...

or something like that.  (It may be interesting to ponder if there is
some other way to specify the action than with lamdas's which could
achieve higher performance.)

One of the things to keep in the back of your mind when designing the
Scheme-level rules and grammar specs is that there should be a way for
the parser to hook directly into the scanner so that the only Scheme
code which is evaluated during parsing is the actions in the parser.

For example, it is OK for the scanner rule to emit a Scheme symbol.
Scheme symbols (or some mapping of Scheme symbols into shorts) could
be a suitable representation of tokens.  But it would not be OK if the
chosen syntax/semantics for scanner rules forces the implementation to
evaluate a Scheme expression in order to determine the emitted token.

>    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).

Well, we need to check this.  But it was my impression that both flex
and bison uses more tables than should be necessary in a vanilla
solution.  My direct thought was that they use extra tricks which make
them faster.  (It's no use arguing with me about this because I don't
know what I'm talking about. :)

>    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.

Sorry, when saying guile-ref I meant the guile-doc package.