Re: SCM-ification of parser

[Han-Wen Nienhuys]

Erik Sandberg wrote:
> > > 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.

Yes, that might be a good implementation idea.

> > I 
> > propose to have
> >
> >   foo:  bar baz
> >      ;
> >
> >
> > =>
> >
> >    (make-syntax-foo .. )
>
> OK. Then I'll change any rule names which I find too complicated.

Yes, the naming in the parser is a complete mess. You're welcome to 
change that too. (eg. "Music" vs. "music")

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

Yes, of course.

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

Don't worry too much about it. --safe only comes  into play if you use #

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

there's currently a couple of modules of lily specific stuff, and all 
user-defined stuff (including what comes from the init files in ly/ ) 
goes into another module.  I think it would be good to create a

  scm/ly-syntax-constructors.scm (or similar)

which is a module used by the parser.

One idea to connect both is to use some C++ macro and SCM initialization 
trickery, to register each MAKE_SYNTAX_EXPRESSION with the Lily_parser 
class, and provide a

  (ly:parser-set-syntax 'music-sequence my-music-sequencer)

hook into that.

>  (I have a feeling that lily currently does something similar with 
> the safe mode, but I don't have a clue really)

I doubt you will need to look into this.

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

Yes.

--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com