Syntax programming with lexemes rather than trees?

[Sorry for the accidental off-list reply, Neil]
On Tue, Mar 23, 2010 at 10:43 PM, Neil Mitchell
It actually sounds like your representation has structure, but you dislike structure because it's hard to work with.
It seems to me like the data has structure, but that data is not treelike! Is a performance a collection of measures or a collection of instruments? A tree-like structure makes you choose, but in truth it is both. I'm not sure I've seen a good solution to this kind of problem in FP. --Max

Hi Max
LilyPond has already answer this one (and ABC can't handle it) -
scores are collections of instrument parts and parts themselves are
made of measures. In practice, I do all assembly at the score/part
level with untyped pretty printing combinators, trying for a typed
representation would be too restrictive - LilyPond has a very large
LaTeX style syntax for assembling scores.
Best wishes
Stephen
On 24 March 2010 11:25, Max Rabkin
Is a performance a collection of measures or a collection of instruments? A tree-like structure makes you choose, but in truth it is both. I'm not sure I've seen a good solution to this kind of problem in FP.

Stephen Tetley wrote:
LilyPond has already answer this one... trying for a typed representation would be too restrictive - LilyPond has a very large LaTeX style syntax for assembling scores.
I find LilyPond's very monolithic very stateful representation to be ugly and awkward. It clearly misses out most of the underlying structure - and in correspondence with the authors on the mailing list there, it is clear that they are aware of this. They chose a certain representation philosophy based on a weird ad hoc blend of Scheme and LaTeX, and they are sticking with it to the bitter end only because it's far too late to turn back. Don't get me wrong - I love LilyPond, it is an absolutely fantastic piece of software. But the kinds of kluges and backflips that you need to get even simple things done sometimes is staggering. Example: when you write a simple lead sheet with named chords, you'll always want to use "chordChanges" mode. But then, if the first chord in the second ending of a volta repeat is the same as the last chord in the first ending, it will be omitted. Because after all, the whole piece is just a linear stream of tokens with no structure. With work you can get the chord to print, but what a mess. And then if you want to change something, you have to undo the whole mess and do it again. You are absolutely right that the structure of music representation is not simple at all. But it is there. Please don't give up. Regards, Yitz

Hi Yitzchak Thanks for the encouragement. Funnily enough its been the working with 'repeat' syntax that has tipped the current revision of my code from being "workable, somewhat ad-hoc, polish-able later" into "horrible - too complex, needs a simpler foundation." As for programming to LilyPond from Haskell, with the latest revision I've managed entirely with the stmap class I posted above (and its pathological extension to a 3 parameter functor - trifunctor?). There isn't a monad in sight in currently. While the results are disappointing at the moment, the domain has been fruitful for cultivating some exotic functional codes: families of unfold functions extending the skipping unfold at the heart of the stream fusion paper [1]; traversals that separate shape from contents [2] and more. Best wishes Stephen [1] http://www.cse.unsw.edu.au/~dons/papers/stream-fusion.pdf further elaborated by Jeremy Gibbons: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/adt.pdf [2] http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/iterator-msfp.pdf
participants (3)
-
Max Rabkin
-
Stephen Tetley
-
Yitzchak Gale