[email protected]
[Top] [All Lists]

Splitting a Hackage project (was ANN: Streaming Component Combinators 0.

Subject: Splitting a Hackage project was ANN: Streaming Component Combinators 0.4
From: Mario Blazevic
Date: Fri, 08 Jan 2010 09:26:06 -0500
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:

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


    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 
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
[email protected]

Libraries mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>
  • Splitting a Hackage project (was ANN: Streaming Component Combinators 0.4), Mario Blazevic <=