Closed HeinrichApfelmus closed 10 years ago
Thanks for the feedback Henrich.
I agree that the complexity grows with the amount of polymorphism, both for the user and the developer (in some cases it grows exponentially). However the libraries are all about the challenge of providing combinators that work with different kinds music.
If I attempted to represent music by a single momomorphic type Music
, I'd first have to decide several things:
In other words, supporting general, rich types with nice semantics is very much what the libraries are all about. Having said that, I believe there are several ways of making the polymorphism more tractable and this is something I am still exploring.
Fair enough.
It's just that the complexity introduced by polymorphism does have a cost, and I interpret the bug that I've reported — events
not respecting the Lens laws — as a sign that this cost is too high. I mean, it's a bug that affects the core functionality, as I am only allowed to manipulate the abstract music types via combinators from lens
, and here is a combinator that doesn't work.
On the benefit side, I have trouble finding actual examples of the possibilities that I might be able to express. For instance, I have never seen a computer representation of Indian music; also I am unlikely to ever need one. As far as representation of music goes, I would say that the MIDI standard is a concrete data type that can express almost all situations and I have trouble finding examples that don't fit (and for which implementing a custom data type would share a lot of common combinators). It's not that MIDI can't be made more elegant, just that it is an example of a concrete data structure that can express most situations.
Of course, this just my opinion appended to a bug report; you have different trade-offs and decisions to make than i do. :smile: But I thought I'd add it anyway, just in case it might be useful.
Speaking of the original bug it has to do with the a semantic/implementation mismatch (arguably caused by bad semantics) of Score
, and is actually unrelated to the polymorphism: you get the same problem with Score ()
.
For instance, I have never seen a computer representation of Indian music; also I am unlikely to ever need one.
With all respect, I thinks this is a typical self-fulfilling prophecy.
It's not that MIDI can't be made more elegant, just that it is an example of a concrete data structure that can express most situations.
Most situations in standard DAW/sequencer style Western/pop/classical. Why do the music on the radio sound about the same? Because it is made in the same software which tends to assume MIDI, 4/4 and BMP=120 ;). Compared to music notation MIDI is known to be limited (see for example this book) which is why formats such as GUIDO and MusicXML exists in the first place.
Thank you, good feedback is always useful ;).
For instance, I have never seen a computer representation of Indian music; also I am unlikely to ever need one.
With all respect, I thinks this is a typical self-fulfilling prophecy.
That's true. What I actually wanted to say is that is that while music-suite
allows the representation of Indian music in principle, it unfortunately does not add a concrete example of doing so. I understand the need to unify two examples, but I'd be hesitant to abstract from just one example without having the other example available in a concrete form.
(This discussion will probably continue elsewhere, closing.)
(First part moved to #297)
On a more general note, your library seems like a great project, but the complexity introduced by polymorphism seems very daunting to me. I'm not entirely sure if it's worth it. Personally, I would probably prefer Pandoc's style with concrete types.