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/
<br><br>Cheers,<br>Christophe (vincenz)<br><br><div><span class="gmail_quote">On 6/30/06, <b class="gmail_sendername">Ashley Yakeley</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In article<br><<a href="mailto:252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net">252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net</a>>,<br> "Bayley, Alistair" <
<a href="mailto:Alistair_Bayley@invescoperpetual.co.uk">Alistair_Bayley@invescoperpetual.co.uk</a>> wrote:<br><br>> Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal<br>> Setup.hs? Would it be much trouble to add them?
<br><br>Bear in mind HNOP compiles just to an executable file, so it doesn't<br>really have a Haskell API.<br><br>One interesting line of development would be to spin off the core<br>functionality into a separate library, to provide no-op services to
<br>other Haskell applications. I'm thinking something like this:<br><br> noop :: IO () -- generalise to other Monads?<br><br>This would actually not be too hard to write, given my existing work,<br>and then of course the executable would simply be a thin wrapper.
<br><br>--<br>Ashley Yakeley<br>Seattle WA<br><br>_______________________________________________<br>Haskell mailing list<br><a href="mailto:Haskell@haskell.org">Haskell@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell">