Re: [Haskell-cafe] Re: Google Summer of Code 2009

gwern0:

On Thu, Feb 12, 2009 at 11:49 AM, John Lato wrote:

...

Johan Tibell wrote:

...

On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa wrote:

...

Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings.

I still haven't figured out what the "correct" definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of "two level" monad. I think that's the reason for the frequent occurrences of >>== and liftI in the code. There seems to be some things we yet have to discover about Iteratees.

I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The "two level monad" part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient.

I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope.

John Lato

I agree. Just packaging and cabalizing something is likely not a SoC-worthy project. (This is why the 'cabalize Wash' suggestion will never make it, for example.) In general, cabalizing seems to be either pretty easy (most everything I've cabalized) or next to impossible (gtk2hs, ghc). The former are too trivial for SoC, and the latter likely are impossible without more development of Cabal - at which point it'd be more correct to call it a Cabal SoC and not a cabalizing SoC.

Yes, "cabalising" was more of a priority when we only had 10 libraries :) So in general, think hard about missing capabilities in Haskell: * tools * libraries * infrastructure that benefit the broadest number of Haskell users or developers. Another route is to identify a clear niche where Haskell could leap ahead of the competition, with a small investment. -- Don