Updated stream/parser todo

[Erik Sandberg]

Hi,

There is a bunch of fairly independent next steps for me. I'd like to start 
with 3, because it's the biggest one, so I can work on 1+2 whenever 3 stalls.

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.

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.
 - Change StreamEvent to a prob, where the event-class is the only immutable 
property.
 - Rename MusicEvent to OldMusicEvent. Change Music::send_to_context to copy 
all properties to an event of the new type MusicEvent which it sends along 
with the OldMusicEvent. I.e., send two separate events, one OldMusicEvent 
with Music embedded, and one MusicEvent with properties set directly.
 - Create a listener system for translators. Each translator should register 
try-music equivalents to events-below listeners using some macro.
 - Replace one try-music at a time into a set of listeners (huge job).
 - make Music send only MusicEvents.
 - it should be safe to remove the translator group's code for calling 
try_musics
 - Change EventChord iterator to use 'events iso 'elements, which initially is 
a mixed list of music and stream events.
 - it's now possible to change all MY_MAKE_MUSICs into stream event creations, 
one by one.
 - rename music-class 'event to 'bottom-event? (event that is sent to bottom 
context, possibly implicitly created)
 - make type-checking work for stream-event properties. I think I'll use 
define-music-properties.scm directly at first, and perhaps split into 
separate lists for music and events later if that looks sensible.
 - perhaps introduce event-function, which maps event to event (as in c-\tag 
#'foo -. )

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.

A related question is whether music macros should return syntax expressions or 
music expressions / stream events, and another question is how to handle 
syntax expressions for event-functions. I'll look into those problems when 
I'm a bit closer.

-- 
Erik