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

Gwern Branwen gwern0 at gmail.com
Thu Feb 12 12:00:27 EST 2009

On Thu, Feb 12, 2009 at 11:49 AM, John Lato <jwlato at gmail.com> wrote:
> Johan Tibell wrote:
>> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.lessa at gmail.com> 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


More information about the Haskell-Cafe mailing list