Message: 7
Date: Tue, 29 Mar 2011 22:39:12 -0400
From: wren ng thornton <wren@freegeek.org>
Subject: Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
To: haskell-cafe@haskell.org
Message-ID: <4D9297D0.7060405@freegeek.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 3/29/11 4:40 AM, oleg@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.

> 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.