Just this weekend I got nhc98 running on a platform where I've wanted a Haskell compiler for a long time, very thrilling. But of course nothing's ever perfect, and apparently there's no foreign import "wrapper" support, which I think is what I would use to pass Haskell functions to C. Is there another way to do that? I'm looking at a C++ API where a class virtual function would call back to a different function for each class instance object, so while "foreign export" is a start, it doesn't do what I need to do. While I'm at it - if I manage to get callbacks working - they'll be coming from various different OS-level threads, so ... I will need to protect against concurrent execution, right? Thanks! Donn Cave, donn@avvanta.com PS The platform is a revived/cloned open source version of BeOS, called "Haiku". Haiku hasn't actually been released yet, but I've run BeOS since it came out ca. '96. I'm sure I'm not the only one who has ever wanted to compile Haskell on BeOS, but likely one of only a handful.
Donn, sorry I didn't see your message until now - it got filtered away to a different mailbox during ICFP.
Just this weekend I got nhc98 running on a platform where I've wanted a Haskell compiler for a long time, very thrilling. But of course nothing's ever perfect, and apparently there's no foreign import "wrapper" support, which I think is what I would use to pass Haskell functions to C.
You are right, nhc98 does not support "foreign import wrapper". The main problem is generating machine code on-the-fly. One possibility would be to steal ghc's Adjustor code. Another route might be to change all the FFI backend code over to using libFFI, as yhc (based on nhc98) has already done, and as I think ghc has also done recently. (However, I believe yhc never attempted to implement "foreign import wrapper" either.)
While I'm at it - if I manage to get callbacks working - they'll be coming from various different OS-level threads, so ... I will need to protect against concurrent execution, right?
nhc98's runtime system is single-threaded, but assuming that the functions you export are pure, I don't see how that is a problem. I suppose you would need somehow to route all callbacks into the OS thread that contained the (single) nhc98 runtime system? Yhc has concurrent Haskell-level threads, but again they are contained within a single OS-level thread. Regards, Malcolm
participants (2)
-
Donn Cave -
Malcolm Wallace