Splitting a Hackage project (was ANN: Streaming Component
mblazevic at stilo.com
Fri Jan 8 09:26:06 EST 2010
I couldn't find any Hackage policy guideline on the appropriate balance
between the package list size and package size, so I'll just ask the
I have released the version 0.4 of my SCC package yesterday. In this
particular release, there is at least one module that's nicely
self-contained, providing useful functionality of its own, and not
expected to evolve much:
My question then is if I should split this module into a separate
package or leave it where it is? If I split it out, what should I do
about the ParallelizableMonad class in the module?
> class Monad m => ParallelizableMonad m where
> bindM2 :: (a -> b -> m c) -> m a -> m b -> m c
This class and its instances would again be something *usable* both
outside the SCC package and outside the Control.Concurrent.Coroutine
module. But would they be *useful* and would they be *used*? Should I
split the class out into a Control.ParallelizableMonad package?
I'm sure I'm not the only one with the same dilemma. It would be nice
to have some written rules to follow on what belongs on Hackage as a
> Version 0.4 of Streaming Component Combinators, or SCC for short, has
> been released on Hackage. Get it at
> There isn't much new high-level functionality compared to the
> previous version, but the implementation has been heavily refactored and
> the foundations completely replaced.
> I'm particularly happy to have found a way to drop the ugly reliance
> on Data.Dynamic and to encode the required constraints in the type
> system instead. The foundation of streaming components in this version
> is the new Control.Concurrent.Coroutine module, whose main export is the monad
> transformer Coroutine. It can transform any monad into a suspendable, resumable,
> trampoline-style-runnable monad. Coroutines can be nested, which was the
> requirement for streaming and the main stumbling block for the implementation.
> The solution, worth at least 10 milliOlegs according to my estimate, was to
> parameterize the Coroutine with a functor that wraps the coroutine suspension,
> and to use nested functors for suspension from nested coroutines. The type system
> automatically figures out how many wrappings to apply to each suspension
> depending on how many intermediate coroutines it suspends.
> In other news is the project's Wiki page at
> http://trac.haskell.org/SCC/wiki/. It's still rudimentary, but growing.
> All feedback will be appreciated.
> Haskell mailing list
> Haskell at haskell.org
More information about the Libraries