18

i.e. is it possible to embed Haskell code in a C library so that the user of the library doesn't have to know Haskell is being used? In particular, so that the user could use multiple libraries that embed Haskell, without any conflicts?

As far as I understand things, you embed between calls to hs_init and hs_exit, but these involve global state shenanigans and should conflict with other calls, no?

Devin Jeanpierre
  • 92,913
  • 4
  • 55
  • 79

1 Answers1

14

Yes, it's possible to call Haskell code from C (and vice versa) through FFI, the Foreign Function Interface. Unfortunately, as the haskell.org docs says, you can't avoid the calls to initialize and finalize the haskell environment:

The call to hs_init() initializes GHC's runtime system. Do NOT try to invoke any Haskell functions before calling hs_init(): bad things will undoubtedly happen.

But, this is interesting also:

There can be multiple calls to hs_init(), but each one should be matched by one (and only one) call to hs_exit()

And furthermore:

The FFI spec requires the implementation to support re-initialising itself after being shut down with hs_exit(), but GHC does not currently support that.

Basically my idea is that you may exploit this specifications in order to write youself a wrapper C++ class that manages the calls to hs_init and hs_exit for you, in example by using template methods surrounded by hs_init and hs_exit that you can override using any haskell call you want. However, beware of interactions with other libraries calling haskell code: nested layers of calls to hs_init and hs_exit should be OK (so it's safe to use libraries which calls them in between your wrappers), but the total number of calls should always match, meaning that if those libraries only initialize the environment without trying to close it, then it's up to you to finish the job.

Another (probably better) idea, without exploiting inheritance and overriding, may be to have a simple class HaskellEnv that calls hs_init in the constructor and hs_exit in the destructor. If you declare them as automatic variables, you'll obtain that the calls to hs_init and hs_exit will always be matched, and the latest call to hs_exit will be made as soon as the latest HaskellEnv object is destructed when you leave its scope. Have a look at this question in order to prevent the creation of objects on the heap (they may be dangerous in this case).

Community
  • 1
  • 1
Riccardo T.
  • 8,907
  • 5
  • 38
  • 78
  • I already know that it's possible. I want to know if it's possible to do it _safely_. – Devin Jeanpierre Jun 21 '12 at 11:58
  • You just have to be careful in calling `hs_init` and `hs_exit` I guess. You may try to code yourself wrapper C++ classes to wrap those calls in a safe manner, but it's up to you. The first way that comes to my mind is to use template methods surrounded by `hs_init` and `hs_exit` that you can override using any haskell call you want. – Riccardo T. Jun 21 '12 at 12:02
  • @Riccardo But what if other libraries call hs_init and hs_exit? – Devin Jeanpierre Jun 21 '12 at 12:08
  • hs_init..hs_exit "blocks" may be nested in such a way that only the outer one really shuts down the system when it's called. This means that you have to be sure that those calls are matched within the libraries you are using. Furthermore, you may add a new hs_init..hs_block yourself wrapping all calls to haskell and all calls to libraries using haskell (in your wrapper classes I mean, so that you only write it once). – Riccardo T. Jun 21 '12 at 12:16
  • @DevinJeanpierre: I expanded a little bit my answer to include this thoughts. – Riccardo T. Jun 21 '12 at 12:31
  • Do you have a citation for the nested call stuff? – Devin Jeanpierre Jun 21 '12 at 12:36
  • @DevinJeanpierre: yes, the second one in my answer. I'm adding a link right now. – Riccardo T. Jun 21 '12 at 12:41
  • Are `hs_init/hs_exit` safe to use in multi-threaded programs? For example, let's have two threads T1, T2. T1 calls hs_init. T2 calls hs_init. T1 does some work and then calls hs_exit. Whoops! This affects T2's hs_init, not T1's! I think you might need to queue `hs_exit`s and have `hs_init`s associate some sort of unique tag. Of course this polling route would be problematic memory-wise. There really ought to be an API more like `struct HsState st; hs_init(&st); ...; hs_exit(&st)`. – Thomas Eding Jun 21 '12 at 20:28