> > Message: 7 > Date: Tue, 29 Mar 2011 22:39:12 -0400 > From: wren ng thornton <w...@freegeek.org> > Subject: Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8 > To: haskell-cafe@haskell.org > Message-ID: <4d9297d0.7060...@freegeek.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 3/29/11 4:40 AM, o...@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.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
