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.

Best wishes

Stephen

On 27 November 2015 at 23:55, Dennis Raddle <dennis.raddle@gmail.com> wrote:
>
>
[snip]
>
>
> I've used the Either monad for exception handling. Yes, I was using do
> notation. This current project is just for myself. Exceptions represent
> either bugs or malformed input. I can catch some of them in the IO monad so
> my program prints an error but keeps running and lets me try again. If the
> program crashes out, no big problem.
>
> I'm parsing MusicXML with Text.XML.Light. The XML is always well-formed.
> However *MusicXML* is not a well-defined language. Like, does every <note>
> element have a child element called <voice>? No guarantee I can find, yet it
> has been true in the examples I've tried with the only typesetter I'm using
> to generate MusicXML.  I can get my program running quickly without
> bothering with the case that <voice> is absent. But if that case someday
> occurs, I want to know precisely and immediately. Yet I don't want to write
> a detailed error message for every violated assumption, of which there are
> dozens necessary. So my solution is to find these things with case
> exhaustions. The program crashes and I have to inspect the code, but no
> problem.
>

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners