Re: SCM-ification of parser

[Erik Sandberg]

On Wednesday 17 May 2006 17:31, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > The next step in parser split-up is to move rules out to Scheme. There
> > will be a lot of functions, so I suggest we create a new make-music.scm
> > for this.
>
> Regarding naming, we already have a make-foo-music for plain SCM use. 

I suppose however that it would be useful for scheme users to get access to 
all the syntax functions (make-syntax-simultaneous will be very similar to 
make-simultaneous-music, for instance). It could at least be good to let 
make-*-music be wrappers around syntax expressions, or vice versa.

> I 
> propose to have
>
>   foo:  bar baz
>      ;
>
>
> =>
>
>    (make-syntax-foo .. )

OK. Then I'll change any rule names which I find too complicated.

BTW, I'd prefer to make syntax expressions that don't completely mirror the 
parse tree. E.g., I'd prefer not to add an extra identity function 
(make-syntax-embedded-scm ) around the SCM_T in
embedded_scm:
        SCM_T
        | SCM_IDENTIFIER
        ;


> It would also be nice if you could fold in various other runtime
> configuration mechanisms (eg. lookup for -| -^ and other scripts, the
> pipeSymbol hack).
ok, I'll look at it
> Also, I'm not sure if -in the long run- you should use
> lily_module_constant. I think it makes more sense to store the
> production rules in the parser object, just like the definition of eg.
> pipeSymbol.

I know little about guile modules, I guess I should read more about them 
(there is currently a risk that I would break the safety of --safe if I'd 
start playing with modules). 

However, it feels like a sensible thing to create a module or two which are 
reserved for the syntax expressions; maybe one 'read-only' one for builtin 
stuff (ie. the contents of syntax-rules.scm), and one for user-defined music 
functions. (I have a feeling that lily currently does something similar with 
the safe mode, but I don't have a clue really)

> > We will need a mechanism for handling music origins in a good way. I
> > suggest that an optional parameter for origin is added to all
> > make-*-music functions (or perhaps even automate this with a
> > define-make-music-function macro)
>
> There is already generic location support from the bison side, using $@
> I think. I think it's best to use that.

Yes, but we still need to pass the $@ on to the make-syntax* functions, right?

-- 
Erik