Erik Sandberg schreef:
1. Interface for exporting/importing music streams:
- refactor global-context-scheme: separate run-translator into three separate
functions:
1 ly:make-global-context: initialise and create empty Global_context
2 ly:make-global-translator: create translators for an empty Global_context
3 ly:interpret-music-expression: iterate music in a global context.
- write Scheme replacements for 2 and 3, which exports / imports streams
- find a good way for a user to export/import streams?
2. Try to completely separate translators and iterators from contexts:
- retrieve get_output from the global translator_group instead of
global_context. Kill the Score_context class.
- make translators keep their own child/parent lists. I think this will make
context::implementation_ unused & junkable, so translators will be separated
from contexts.
- create separate class Iterator_outlet, which contains the Context methods
and members that are specific to music iteration.
sounds good.
3. Make translators listen to stream events, and make MusicEvent stream-events
contain properties directly. Furthermore, represent all events as stream
events rather than music from the beginning. I think this will take some
time.
Question: how will you deal with all the Scheme user code that this
change will break? Every music function nowadays uses ly:music-property
on XxxxEvents.
I'm not convinced that this clean-up is worth the effort.
4. Delay the evaluation of syntax-expressions, and softcode relative as a
macro. I'd prefer to wait with this until after 3, for typechecking reasons
(it would feel good to settle the distinction between stream-events and music
first). There are basically two ways to evaluate syntax-expressions:
- Evaluate the expression directly. This can actually be implemented more
robustly than it first sounds: If all syntax constructors are created with
define-ly-syntax, then we can create typechecking/error-detecting wrappers
around each user-defined function.
- The parser can evaluate the expression manually, by traversing it and
recursively calling all functions.
I prefer the 2nd actually. I think that the order argument evaluation
for Scheme functions is not specified, which may lead to surprises if
they have side effects. Secondly, the 2nd option will make it easier to
prevent unexpected leaking of information (of the syntax module, or the
ly file) into the music expressions.
--
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
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
