Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

Hi Henning Thanks - yes, there is a report by Matt Munz, a student of Paul Hudak's. Last year I tried to get my library to work with Haskore, but Haskore has numerical durations - for scores you need symbolic ones, and its a lot of work deriving symbolic durations from numeric ones. There are few

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

Stephen Tetley schrieb: Hello All Modern functional programming languages give you algebraic data types that are mighty convenient for programming with syntax trees. However, I'm working in a domain (music typesetting) where modelling syntax with trees can be problematic and I'm wondering whethe

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

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 fro

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

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 m

[Haskell-cafe] 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 wrote: > 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 treelik

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

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

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

Hi Neil Thanks - music has has lots of structure, true, but unfortunately the structure is often arbitrary, sometimes even conflicting (with respect to a nested representation). I've tried various representations: plain algebraic data types, HOAS, generics with KURE, tagless, attribute grammar wi

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

Hi Stephen, It actually sounds like your representation has structure, but you dislike structure because it's hard to work with. The solution is a generics library, and I recommend Uniplate: http://community.haskell.org/~ndm/uniplate Imagine you have a ridiculously complex AST, with beam groups u

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

Hi Malcolm Thanks - particularly I don't want to go to an AST because its I'm finding it too convoluted 'shape wise' - processing beam groups inside tuplets etc. is a nightmare - music representations have had at least eight centuries of ad hoc extension. I know Norman Ramsey and colleagues paper

Re: [Haskell-cafe] Syntax programming with lexemes rather than trees?

I'm working in a domain (music typesetting) where modelling syntax with trees can be problematic and I'm wondering whether I should work at a lower level - essentially a list / stream of lexemes and some notion of a context stack for processing, tracking when I'm inside a tuplet and the met

[Haskell-cafe] Syntax programming with lexemes rather than trees?

Hello All Modern functional programming languages give you algebraic data types that are mighty convenient for programming with syntax trees. However, I'm working in a domain (music typesetting) where modelling syntax with trees can be problematic and I'm wondering whether I should work at a lower