You may be interested in the approach outlined in Wouter Swierstra's paper "Data Types a la Carte". There is also the 'syntactic' package which is based on Wouter's ideas. This is exactly the problem it was trying to solve -- having several slightly different versions of a data type, *without* having to do a lot of repetition (as in your separate data types approach) or throwing away the type system's help (as in your approach with Maybes). In any event it's a fun paper to read. -Brent On Fri, Jan 27, 2012 at 08:59:00PM -0800, Dennis Raddle wrote:
I'm working on an application for reading Music XML and manipulating it, including translating it into midi events.
Storing music data can take place from different perspectives or requirements.
- a literal translation of the MusicXML would store each note and marking on the page
- another representation might relate to higher concepts: for instance, instead of storing individual dynamic markings and indications for swelling and ebbing of dynamics, it might create a single data structure which is a dynamic profile over time. Instead of storing all the markings over the notes individually (staccato, accents, slur marks, etc.) it might examine all the markings at once and compute concrete performance instructions note by note.
There are about four distinct stages in processing the music, in which things become either more abstract (grouping together details into higher concepts) or more concrete (such as more literal performance instructions).
One of the stages, by the way, tries to represent notes in a way such that they can be moved in time or "sliced out" without disturbing the continuity of the performance instructions.
At first I created several different data structures, one for each useful stage. Many of the fields are copied literally. There are similar fields which need distinct names. This is starting to seem like a confusing mess.
Another approach is to create one data structure which contains some "Maybe" type fields. When the processing reaches a certain stage, they are set to "Just <value>" if applicable to that stage. Otherwise they are set to Nothing.
I didn't want to do this at first because it's too much like a sloppy script language. The type system of the compiler would no longer assist me in verifying the validity of the data at each stage.
But it's turning into a mess- and the key reason it's a mess, I think, is that I DON'T have a clear model of the stages. It keeps changing as I expand the requirements of my program. What seemed like a useful representation last month needs to be changed today.
Any ideas welcome.
Dennis
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners