Re: Updated stream/parser todo

[Han-Wen Nienhuys]

Erik Sandberg schreef
> > This doesn't sound like a very clean solution, which is troublesome
> > given that the original (IIRC) motivation was to clean things up.
>
> Not necessarily; the unclean workarounds are temporary and isolated, and will 
> only last until we decide to drop backward compatibility.

I don't see the point of temporary workarounds: either we solve a 
problem completely or we don't. There's nothing as long-lasting as a 
temporary workaround.

> In any case, I think I've found a decent alternative: We can let all music 
> events stay more-or-less as they are, but junk event-chords (use 
> simultaneous-music instead), and make music-events use their own iterators. 
> These iterators will perform any necessary duration-callbacks etc, and then 
> create and send a stream event around each music-event's mutable property 
> alist.

Yes, sounds like a sensible alternative.

> Regardless of what we decide as the 'final' music expression format, this 
> feels like a good intermediate step.
>
> BTW: May I change Sequential_iterator::get_music_list to return something like
> scm_call_1 (get_music ()->get_property ("child-list-callback"), get_music 
> ()->self_scm ());
> ?
>
> This would make it possible to soft-code e.g. percent-repeat-iterator.

Why?  If you want to make thing softcodable, why don't you make 
iterators themselves softcodable? ie. init the virtual functions with 
Scheme procedures.

  (ly:make-scm-iterator my-process my-pending-mom my-construct-children)

but, all in all, I don't see what advantage this would get us.

--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

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