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-Concurr... 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell