I once worked for a company at which HNOP could be used as a drop-in replacement for half the programmers. -Greg On 6/30/06, Christophe Poucet <christophe.poucet@gmail.com> wrote:
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 <ashley@semantic.org> wrote:
In article <252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net>, "Bayley, Alistair" < Alistair_Bayley@invescoperpetual.co.uk> 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