On 3/11/07, Udo Stenzel
do uri <- maybe (fail "broken uri") return $ parseURI uriStr doc <- either throwDyn return =<< evenSimplerHTTP uri parsed <- either throwDyn return $ parse grammar uriStr doc
...untested of course, and only intended to show the principle.
Ah, thank you for the interesting example! There are definitely some good ideas here. But I'm still concerned that this approach won't scale. In languages with better-developed library archives (Ruby, Perl, etc.), I frequently use over a dozen third-party libraries in one program. And that's the direction Hackage and cabal-install will be taking the Haskell community. I'm very sensitive to noise in code. I want my programs to be uncluttered, perhaps even beautiful (though I rarely achieve that goal). So the idea of using a bunch of little helper functions to adapt all the different error-reporting conventions bothers me. I mean, why is the error-reporting so interesting that it belongs right in the main program flow? In general, Haskell encourages programmers to hide irrelevant details in monads, and keep the main program clean. This would certainly be easier if we had more consistent error-reporting styles. But for now, at least, I'll definitely benefit from your suggestions. Many thanks! Cheers, Eric