Make GHCi load and interpret a module with a "foreign export" declaration (for FFI with C)?

Question

I have a module (Safe.hs) with

foreign export ccall respond_hs :: CWString -> IO CWString

for FFI with C.

I'd like to load Safe.hs in GHCi and evaluate some things with it.

But ghci fails to load it (I'm specifying two source files because it depends on valencies.lhs):

$ ghci src/valencies.lhs src/Safe.hs 
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 2] Compiling Valencies        ( src/valencies.lhs, interpreted ) [flags changed]

[2 of 2] Compiling Safe             ( src/Safe.hs, interpreted )

src/Safe.hs:10:1:
    Illegal foreign declaration: requires via-C, llvm (-fllvm) or native code generation (-fvia-C)
    When checking declaration:
      foreign export ccall "respond_hs" respond_hs
        :: CWString -> IO CWString
Failed, modules loaded: Valencies.
*Valencies> :q
Leaving GHCi.
$ 

Giving -fvia-C option doesn't help.

Related questions

• This is a different question from Testing FFI Code with GHCi, where the point was in testing Haskell code with foreign import (not export) from C libraries.

• GHCi doesn't work with FFI export declarations/shared libaries seems strange to me, because it doesn't help me. It deals with foreign export from Haskell to C, but the problem solved there is some missing object files.

Answer 1

Actually, as told by Dirk Thierbach, there are two helpful options in this case:

If you look up -fvia-C in the GHC manual, section flag reference, you're redirected to section 4.10.6 (Options affecting code generation). There you'll find, near -fvia-C:

-fobject-code

Generate object code. This is the default outside of GHCi, and can be used with GHCi to cause object code to be generated in preference to bytecode.

-fbyte-code

Generate byte-code instead of object-code. This is the default in GHCi. Byte-code can currently only be used in the interactive interpreter, not saved to disk. This option is only useful for reversing the effect of -fobject-code.

That explains why it works with GHC, but not with GHCI.

So, I happily do ghci -fobject-code src/valencies.lhs src/Safe.hs now.

Related questions

• GHCi doesn't work with FFI export declarations/shared libaries first seemed a mess to me, because it didn't help me. It deals with foreign export from Haskell to C, too, but the problem solved there is some missing object files, which you must give to GHCi for it to link everything. In my case, I simply omit linking with the C part of the program, because I don't need it to test the Haskell module. After re-reading that Q&A, I can suspect that giving an .o to GHCi can simply silently switch GHCi to the correct mode!

If all you want is to test the Haskell module, and if its functions can work in isolation from C functions (i.e., they don't call C functions), I believe the option I have discovered is a simpler way than to add more .o files to the command line to make GHCi link everything (you see, there might be further requirements to link with some C functions from other packages, which is not important for you).