On Sat, Nov 28, 2015 at 2:14 AM, Stephen Tetley <stephen.tetley@gmail.com> wrote:

Hi Dennis

For this use case I would make a small, general parser combinator
library / monad on top of XML.Light, then use the new parser
combinators to make a specialized parser for your subset MusicXML.

The common parser combinator libraries (Parsec, Attoparsec, ...) can't
be used with XML.Light because their mechanics are consuming an input
stream whereas processing XML (or JSON) is moving a cursor through a
tree, but the common API provided by parser combinator libraries can
be re-used productively for a tree (cursor) parser. As well as moving
the cursor, the custom parser monad can handle errors and backtracking
if needed.

Thanks for the pointers, Stephen. I will look into it. I don't know if I'll have time to learn how to do this though. I'll keep it in mind for the future.

This is a small, ongoing, no-pressure project, which is even lower pressure when you consider I'm using what I call "just in time" debugging and design. When I look at my use cases, I don't implement any that seem unlikely. If they ever do occur, I can deal with them then. But I don't just ignore cases willy-nilly -- I always consider if they do occur, that the resulting bug will be obvious right away and lead me directly to the answer.

This is interesting when dealing with music playback. Some unexpected cases won't give an error message but will affect the playback sound -- so I always ask myself, "Will this bug be obvious, really screw up the sound in a major way, so I know it's happening?" Because what I don't want are bugs that create small effects that I might miss for a while so I miss the critical moment they were introduced.

I don't know the definition of the different processes but does "Just In Time" design/debugging have something to do with Agile?