Tomasz Zielonka wrote:
On Tue, Mar 07, 2006 at 04:35:27PM -0000, Brian Hulley wrote:
A third point is, how would I pass an arbitrary monad instead of just using IO?
What for? IO is the monad that most closely matches the imperative, C semantics. That's why FFI only supports the IO monad (and pure functions). Other monads (you say arbitrary) may use rather complicated machinery to implement their semantics (HOFs, laziness, algebraic data types). I don't think it's a good idea to try implementing their actions in C (if that's what you want).
Why do you need that?
I'm writing a library in C++ that will provide a GUI application framework, where the Haskell main function will simply describe the initial GUI configuration and supply callback functions. The C++ library will then just sit in a windows event loop calling the relevant Haskell callbacks. The question arises as to how to store and modify the application's state without having to make too many assumptions in advance as to how this state should be represented, so it seems natural for the callbacks to have a signature like mycallback :: GUIMonad m => EventInfo -> m EventResult 'm' will have to combine a state monad with the IO monad (so I can use IORef etc if needed). Of course I could just use IO by itself eg return IO (State, EventResult) but this seems a bit messy... There are some elements of the monad that C++ code will need to know about (to make use of the EventResult), but it would be nice to also have some elements that are private to the Haskell side so that different kinds of app framework can be used (eg apps based on a dependency graph architecture) without having to re-write my C++ DLL... Also, it might be nice to prevent the callback functions from doing any input, and like O'Haskell, just provide some sort of O monad although I'm not worried about this at the moment. Regards, Brian.