Message: 7 Date: Tue, 29 Mar 2011 22:39:12 -0400 From: wren ng thornton 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.

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.