On Tue, Feb 23, 2010 at 00:39, Bryan O'Sullivan <b...@serpentine.com> wrote: > On Mon, Feb 22, 2010 at 2:38 PM, Magnus Therning <mag...@therning.org> > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe