Erik Sandberg schreef:
On 5/18/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Erik Sandberg schreef:
> 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.
But the other sequential-music is defined in a different module, so
there should be no problems with namespace clashes, or?
>> (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.
how? According to my plan, the functions do that themselves (by being
either macros or functions). Perhaps my plan differs from yours?
Yes, but I think it's useful to keep the connection between the
productions in parser.yy, and the lisp code that is generated. I'm not
yet convinced that generating a large expression and eval'ing that is a
the best way to go through with this; it seems very unstructured. Let's
move one step at a time.
It's a also a tad more efficient, but that's a secondary concern.
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).
Well, that makes sense.
2. because it would allow a user to override an individual syntax
production rule cleanly.
OK. Why would a user want to do that?
In some cases, that's already possible now, eg. with pipeSymbol.
Another example: we could use this mechanism for invoking all the
different toplevel-{music,score,book}-handlers.
--
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
