Re: SCM-ification of parser

[Han-Wen Nienhuys]

Erik Sandberg schreef:
> I realised that there's a thinko in this naming convention: 
> (make-syntax-foo ...) _is_ a syntax expression, and it _makes_ a music 
> expression. 

yes.

> If we use a separate module for syntax expressions, why not just say foo? 
> e.g.:
> (sequential-music .. )
> for a syntax expression that represents (and, incidentally, produces music 
> which represents) sequential music.

because we already have those, and we risk compatibility breakage if we 
use them to hook into the parser.

> A patch for sequential, simultaneous and repeated music is attached. No fancy 
> module tricks are used yet, but everything is done through macros that can be 
> changed.
>
> > 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)
>
> I don't understand. Why would the parser be interested in knowing which syntax 
> functions that exist? AFAICS it should be sufficient for the parser to just 

1. because the parser also determines which ones are called.  We could 
use this to generate documentation for the syntax/grammar automatically 
(something which is now done manually in the docstrings of the music 
types).

2. because it would allow a user to override an individual syntax 
production rule cleanly.

> ;; TODO: use separate module for parser.
> (define define-syntax define-public)

careful: I think the word "syntax" has connotations in the scheme world 
too. Better use "lily-syntax" or similar. Can you change that? The rest 
of the patch looks ok; commit if it doesn't break make web.



--

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

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