On Sun, 2009-10-18 at 19:53 +0400, Alexey Khudyakov wrote: > > Yes. We decided that having the Get monad as a lazy state monad just > > doesn't make sense. It makes this one use case work, but causes more > > problems generally. Certainly we need to be able to do lazy binary > > deserialisation too, but our feeling is that it should be more explicit > > and integrate better with error handling. Using a lazy state monad gives > > us neither. > > This is valid point. I think I'll just use variant with explicit laziness. > > > > Note also that if we changed runGetState to do any error handling that > > this would also break the lazy state monad properties that you were > > previously relying upon. > > I'd appreciate addition of error handling very much. Currently I have > to use ErrorT and do checks by hands. I have very simple parsers so > it's possible. It's not possible to do such things in general. > > Trading laziness for error handling is good thing I believe. At the > moment it's hard to decode possibly malformed data.
It's possible to have both error handling and lazyness by extending the result to include the representation of the errors. Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
