On Sun, 4 Jul 2010, Michael Mossey wrote:
Serguey Zefirov wrote:
The thing that is hard for me to understand is how, in a functional paradigm, to update the entire Doc by chasing down every tie and making all necessary updates.
This looks like one of graph algorithms.
Notes are nodes, ties are arcs. Measures, etc are parts of node label.
soundedEnd property can be computed over this.
Actually, it would be wise to parametrize Item with computed attributes so that you can clearly distinguish between documents where soundedEnd is set from documents where it is not.
Ah, this sounds like something I am looking for... parameterizing Item with the computed attributes. But I am not clear about what that would look like. Would Item have kind * -> *? Like
data Item c = Item {pitch::Pitch, end::Loc, computed::c}
?
I like to support static distinction between raw and processed Measure data. It makes your code clearer and safer. You may define data Item end = Item {pitch::Pitch, end::end} where 'end = Bool' for raw data, and 'end = Loc' for processed data. (I'm not entirely sure, I understood your representation properly, thus the particular type examples for 'end' may be inappropriate.)