On Fri, Nov 27, 2015 at 2:51 PM, Jeffrey Brown <jeffbrown.the@gmail.com> wrote:

In parsing libraries for Haskell the "parse" function (or its equivalent) typically returns an Either. For instance there's

parse :: Stream s Identity t => Parsec s () a -> SourceName-> s -> Either ParseError a

in Text.Parsec.Prim. This is an example of making invalid state impossible. parse could return a list of all possible parses, with the empty list signifying that parsing failed. But by using an Either, the case of failure can be distinguished as a Left. Haskell will know to treat the Left differently, and if you need an error report, that left can bubble (through multiple Either-returning functions, with some handy do-notation) up to the user without ever invoking an exception to the ordinary control flow.

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.