Re: Updated stream/parser todo

[Han-Wen Nienhuys]

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 - address@hidden - http://www.xs4all.nl/~hanwen

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