[Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[wren ng thornton]

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.


> 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 think a big part of the problem is that we don't have a good type 
theory for coroutines. The idea of functions that "never return" just 
doesn't cut it. And conflating legitimate control-flow manipulation with 
bottom doesn't either. But, as of yet, that's all we've got.

-- 
Live well,
~wren