Splitting a Hackage project (was ANN: Streaming Component Combinators 0.4)

Mario Blazevic 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 
question.

	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:

http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concurrent-Coroutine.html

	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 
separate package.


> Version 0.4 of Streaming Component Combinators, or SCC for short, has
> been released on Hackage. Get it at
> 
> http://hackage.haskell.org/package/scc
> 
>     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
> http://www.haskell.org/mailman/listinfo/haskell
> 



More information about the Libraries mailing list