[Haskell-cafe] Re: Google Summer of Code 2009
dons at galois.com
Thu Feb 12 12:12:53 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
Yes, "cabalising" was more of a priority when we only had 10 libraries :)
So in general, think hard about missing capabilities in Haskell:
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.
More information about the Haskell-Cafe