
On Tue, Feb 23, 2010 at 00:39, Bryan O'Sullivan
On Mon, Feb 22, 2010 at 2:38 PM, Magnus Therning
wrote: My thoughts went more like a parser type like
data Parser e a = ...
Yes, I knew that's where you were going :-) The trouble is, you'd still have to deal with fail :: Monad m => String -> m a which would require your failure type to somehow accept a string. Plumbing that in would be a little more awkward than your initial exporations suggest :-\ You have two problems. The first is how to construct a value of your failure type that accepts a String parameter so that you can support users of "fail". The second is that you might need to pass extra information to construct your failure value when naïve code uses fail or mzero, otherwise you will only get useful error values out quite infrequently.
Yes, I suspected there'd be something I had missed. I guess it'd would require 'Parser e a' to have a 'fail' that's similar to the one in 'Maybe'. Users would then be forced to use '>' to get useful error info out. Would that be an unworkable situation?
I still haven't convinced myself that this will work though. Also, I had a look at attoparsec on bitbucket, and there are some major changes between 0.7 and 0.8.
Even though those changes represent a major modification to the internals of attoparsec, they shouldn't really affect what you want to do, or anything interesting about how to do it.
Ah, that's good. I think I'll have to postpone any work on this for now though, and instead implement a 'String -> MyErrorType' function for, hopefully, temporary use. I've already been sidetracked twice before ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe