I don't understand how this turned into an argument about simplicity. I never said it was complex.
i wasn't arguing, just confused about what you were asking cuz i didn't see what wasn't straightforward. so i addressed the straightforward interpretation in order to ask what that was missing. :) looks like polyphony is the issue, so i think you need a directed acyclic graph (DAG).
since every note has at most one pre-Tie and one post-Tie, i guess you don't need a general DAG -- but a graph library would have the algorithms for walking the Ties (ie, dfs, components, reachable, etc. in the mentioned library).
I conceive of this problem as multiple passes. On the first pass, I translate XML notes into a convenient internal representation, on the second pass sort them, then make a pass to figure out ties. Whether this is the best approach, I do not know.
sure that makes sense, i was just addressing the last pass, the matter of wiring up the tie references.
Regarding my use of Rational, it's because I'm representing *notated* durations or positions in time, which are always fractions of integers. Suppose I give the command to my program to play via midi everything from bar 1 beat 1 to bar 2 beat 2 1/2. I want to use Rational so I know 2 1/2 means 2 1/2 and not 2.49999999999.
i wasn't suggesting anything Numeric for durations -- those are NoteDurs like (Dotted $ Triplet Half). you don't need numerics until resolving temporal locations, like milliseconds or subdivisions of a beat. those may be irrational numbers (consider if the tempo is irrational, or tiny random jitter in timing) -- though it's a totally pedantic point on my part and realistically won't matter. ;)
I don't quite get this:
> forall x. (Real x, Fractional x) => x if you're picky.
just being agnostic about the true representation as long as you have (/), compare, realToFrac, toRational. the client can choose some concrete representation like Rationals, Floats, Doubles, some Fixed resolution, some C type, something they make up, etc. space or speed or compatibility may trump precision for some applications.
(*) I may want to use the location of a note (bar and beat) as the key in a Map, which I believe should be done with Rational and not Float.
location needs subdiv, which is (very pedantically) not Rational. :)
-e