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

[Don Stewart]

gwern0:
> 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
> 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