Re: ANNOUNCE: enumerator, an alternative iteratee package
From: Magnus Therning <magnus@therning.org>
On 24/08/10 03:47, John Millikin wrote: [...]
I would like to avoid hard-coding the error type to SomeException, because it forces libraries to use unsafe/unportable language features (dynamic typing and casting). However, given the apparent practical requirement that all iteratees have the same error type, it seems like there's no other choice.
I haven't worked enough with iteratees to have an informed opinion on this, but I wonder what the pros and cons are of having an error state in the iteratees at all. In other words, why would this
data Step a m b = Continue (Stream a -> Iteratee a m b) | Yield b (Stream a) | Error E.SomeException
be preferred over this
data Step a m b = Continue (Stream a -> Iteratee a m b) | Yield b (Stream a)
(Maybe with the restriction that m is a MonadError.)
Oleg included the error state to enable short-circuiting of computation, and I guess everyone just left it in. Recently I've been wondering if it should be removed, though, in favor requiring explicit (i.e. explicit in the type sig) exceptions for everything. I'm not sure if that would be more or less complicated. John
John Lato <jwlato@gmail.com> writes:
Oleg included the error state to enable short-circuiting of computation, and I guess everyone just left it in. Recently I've been wondering if it should be removed, though, in favor requiring explicit (i.e. explicit in the type sig) exceptions for everything. I'm not sure if that would be more or less complicated.
If you don't want to go all the way to checked exceptions, MonadCatchIO could also be a nice way to go here. G -- Gregory Collins <greg@gregorycollins.net>
On Tue, Aug 24, 2010 at 7:16 PM, Gregory Collins <greg@gregorycollins.net>wrote:
John Lato <jwlato@gmail.com> writes:
Oleg included the error state to enable short-circuiting of computation, and I guess everyone just left it in. Recently I've been wondering if it should be removed, though, in favor requiring explicit (i.e. explicit in the type sig) exceptions for everything. I'm not sure if that would be more or less complicated.
If you don't want to go all the way to checked exceptions, MonadCatchIO could also be a nice way to go here.
Be *very* careful of combining MonadCatchIO and CPS: the MonadCatchIO instance for ContT does not perform correctly, and can call the exception handler twice. It might produce other erroneous behavior, but that was a bug that plagued me in persistent.
I would recommend looking at the failure package[1] for making the exceptions explicit in the type signature. Michael [1] http://hackage.haskell.org/package/failure
On Tue, Aug 24, 2010 at 05:12, John Lato <jwlato@gmail.com> wrote:
Oleg included the error state to enable short-circuiting of computation, and I guess everyone just left it in. Recently I've been wondering if it should be removed, though, in favor requiring explicit (i.e. explicit in the type sig) exceptions for everything. I'm not sure if that would be more or less complicated.
The first few iterations of the "enumerator" package use explicit error types, but this makes it very difficult to combine enumerator-based libraries. The only way I could get everything to work correctly was to always set the error type to SomeException, which is equivalent to and more verbose than making SomeException the only supported type. I believe relying on the MonadError class would have the same drawback, since (as far as I know) it's not possible to create MonadError instances which can accept multiple error types.
participants (4)
-
Gregory Collins -
John Lato -
John Millikin -
Michael Snoyman