[Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[John Lato]

>
> Message: 7
> Date: Tue, 29 Mar 2011 22:39:12 -0400
> From: wren ng thornton <wren at freegeek.org>
> Subject: Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
> To: haskell-cafe at haskell.org
> Message-ID: <4D9297D0.7060405 at freegeek.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/29/11 4:40 AM, oleg at okmij.org wrote:
> > Wren Thornton wrote:
> >> This is often conflated with the iteratee throwing an error/exception,
> >> which is wrong because we should distinguish between bad program
> >> states and argument passing.
> >
> > I guess this is a matter of different points of view on exceptions.
>
> The problem is not so much the exceptions per se (one goto is about as
> good as any other), it has more to do with the fact that important
> things are being left out of the types.
>
> One of the great things about Haskell is that you can lean so heavily on
> the type system to protect yourself when refactoring, designing by
> contract, etc. However, if there's an unspoken code of communication
> between specific enumerators and iteratees, it's very easy to break
> things. This is why the communication should be captured in the types,
> regardless of the control-flow mechanism used to implement that
> communication. I'd like the static guarantee that whatever special
> requests my iteratee could make, its enumerator is in a position to
> fulfill those requests (or die trying). Allowing for the iteratee to be
> paired with an enumerator which is incapable of handling its requests is
> a type error and should be treated as such.
>

This has long been a goal of mine for iteratee (since before the 0.4
release), although I haven't really done any work on it.  Maybe it's time to
see if I can get a more satisfactory implementation.


> > Wren Thornton wrote:
> >> In an ideal framework the producers, transformers, and consumers of
> >> stream data would have a type parameter indicating the up-stream
> >> communication they support or require (in addition to the type
> >> parameters for stream type, result type, and side-effect type).
> >
> > Very true. Currently the design of Iteratees quite resembles that of
> > Control.Exception: everything can throw SomeException. Ideally one
> > would like to be more precise, and specify what exceptions or sorts of
> > exceptions could be thrown -- by Iteratees, and by ordinary Haskell
> > functions. The design of a good effect system is still the topic of
> > active research, although there are some encouraging results.
>
> Yeah, I'm not a big fan of extensible exceptions either. Don't get me
> wrong, it's an awesome hack and it's far cleaner than the Java approach;
> but it still goes against my sensibilities.
>

I've come around to the view that exceptions are a bad idea (in Haskell),
and just making everything explicit (via Maybe, ErrorT, explicit-exceptions,
or otherwise) is the best approach at present.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110331/c75c47f9/attachment.htm>