I do think that refactoring this to a library would be a much better idea.  That way we can see how this scales to multithreaded applications.  Will there be a HNOP 2.0 that takes advantage of such fancy features such as MPTC or FD?  It would be interesting to see how this problem reduces when one uses these advanced Haskell features.  Perhaps as showcase to show that MPTC and FD definitely improve code-readability and design-abstraction/

Cheers,
Christophe (vincenz)

On 6/30/06, Ashley Yakeley <[EMAIL PROTECTED]> wrote:
In article
<[EMAIL PROTECTED]>,
"Bayley, Alistair" < [EMAIL PROTECTED]> wrote:

> Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal
> Setup.hs? Would it be much trouble to add them?

Bear in mind HNOP compiles just to an executable file, so it doesn't
really have a Haskell API.

One interesting line of development would be to spin off the core
functionality into a separate library, to provide no-op services to
other Haskell applications. I'm thinking something like this:

  noop :: IO ()  -- generalise to other Monads?

This would actually not be too hard to write, given my existing work,
and then of course the executable would simply be a thin wrapper.

--
Ashley Yakeley
Seattle WA

_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Reply via email to