<div dir="ltr">> <span style="font-size:12.8px"> (Parsec, Attoparsec, ...) can't</span><br style="font-size:12.8px"><span style="font-size:12.8px">> be used with XML.Light because their mechanics are consuming </span><div><span style="font-size:12.8px">> an input </span><span style="font-size:12.8px">stream whereas processing XML (or JSON) is </span></div><div><span style="font-size:12.8px">> moving a cursor through a </span><span style="font-size:12.8px">tree</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Stephen, the "consuming an input vs. moving a cursor through a tree" distinction you're drawing is unclear to me. Can you elaborate, or provide references? </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Also, Text.JSON.Parsec [1] would appear to be a counterexample to your claim.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[1] <a href="https://hackage.haskell.org/package/json-0.9.1/docs/Text-JSON-Parsec.html">https://hackage.haskell.org/package/json-0.9.1/docs/Text-JSON-Parsec.html</a></span><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 28, 2015 at 2:14 AM, Stephen Tetley <span dir="ltr"><<a href="mailto:stephen.tetley@gmail.com" target="_blank">stephen.tetley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dennis<br>
<br>
For this use case I would make a small, general parser combinator<br>
library / monad on top of XML.Light, then use the new parser<br>
combinators to make a specialized parser for your subset MusicXML.<br>
<br>
The common parser combinator libraries (Parsec, Attoparsec, ...) can't<br>
be used with XML.Light because their mechanics are consuming an input<br>
stream whereas processing XML (or JSON) is moving a cursor through a<br>
tree, but the common API provided by parser combinator libraries can<br>
be re-used productively for a tree (cursor) parser. As well as moving<br>
the cursor, the custom parser monad can handle errors and backtracking<br>
if needed.<br>
<br>
Best wishes<br>
<br>
Stephen<br>
<br>
On 27 November 2015 at 23:55, Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br>
><br>
><br>
[snip]<br>
<span class="im HOEnZb">><br>
><br>
> I've used the Either monad for exception handling. Yes, I was using do<br>
> notation. This current project is just for myself. Exceptions represent<br>
> either bugs or malformed input. I can catch some of them in the IO monad so<br>
> my program prints an error but keeps running and lets me try again. If the<br>
> program crashes out, no big problem.<br>
><br>
> I'm parsing MusicXML with Text.XML.Light. The XML is always well-formed.<br>
> However *MusicXML* is not a well-defined language. Like, does every <note><br>
> element have a child element called <voice>? No guarantee I can find, yet it<br>
> has been true in the examples I've tried with the only typesetter I'm using<br>
> to generate MusicXML. I can get my program running quickly without<br>
> bothering with the case that <voice> is absent. But if that case someday<br>
> occurs, I want to know precisely and immediately. Yet I don't want to write<br>
> a detailed error message for every violated assumption, of which there are<br>
> dozens necessary. So my solution is to find these things with case<br>
> exhaustions. The program crashes and I have to inspect the code, but no<br>
> problem.<br>
><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Jeffrey Benjamin Brown</div></div>
</div>