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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
