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.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
