gwern0: > On Thu, Feb 12, 2009 at 11:49 AM, John Lato <jwl...@gmail.com> wrote: > > Johan Tibell wrote: > >> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.le...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe