How to find out the C type signature corresponding to a Haskell function type in FFI?

[Brian Hulley]

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.