<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Message: 7<br>
Date: Tue, 29 Mar 2011 22:39:12 -0400<br>
From: wren ng thornton <<a href="mailto:wren@freegeek.org">wren@freegeek.org</a>><br>
Subject: Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8<br>
To: <a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
Message-ID: <<a href="mailto:4D9297D0.7060405@freegeek.org">4D9297D0.7060405@freegeek.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 3/29/11 4:40 AM, <a href="mailto:oleg@okmij.org">oleg@okmij.org</a> wrote:<br>
> Wren Thornton wrote:<br>
>> This is often conflated with the iteratee throwing an error/exception,<br>
>> which is wrong because we should distinguish between bad program<br>
>> states and argument passing.<br>
><br>
> I guess this is a matter of different points of view on exceptions.<br>
<br>
The problem is not so much the exceptions per se (one goto is about as<br>
good as any other), it has more to do with the fact that important<br>
things are being left out of the types.<br>
<br>
One of the great things about Haskell is that you can lean so heavily on<br>
the type system to protect yourself when refactoring, designing by<br>
contract, etc. However, if there's an unspoken code of communication<br>
between specific enumerators and iteratees, it's very easy to break<br>
things. This is why the communication should be captured in the types,<br>
regardless of the control-flow mechanism used to implement that<br>
communication. I'd like the static guarantee that whatever special<br>
requests my iteratee could make, its enumerator is in a position to<br>
fulfill those requests (or die trying). Allowing for the iteratee to be<br>
paired with an enumerator which is incapable of handling its requests is<br>
a type error and should be treated as such.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> Wren Thornton wrote:<br>
>> In an ideal framework the producers, transformers, and consumers of<br>
>> stream data would have a type parameter indicating the up-stream<br>
>> communication they support or require (in addition to the type<br>
>> parameters for stream type, result type, and side-effect type).<br>
><br>
> Very true. Currently the design of Iteratees quite resembles that of<br>
> Control.Exception: everything can throw SomeException. Ideally one<br>
> would like to be more precise, and specify what exceptions or sorts of<br>
> exceptions could be thrown -- by Iteratees, and by ordinary Haskell<br>
> functions. The design of a good effect system is still the topic of<br>
> active research, although there are some encouraging results.<br>
<br>
Yeah, I'm not a big fan of extensible exceptions either. Don't get me<br>
wrong, it's an awesome hack and it's far cleaner than the Java approach;<br>
but it still goes against my sensibilities.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>John L.</div></div><br>