Hi
Neil Mitchell is working on a ultra-optimizing C backend for Yhc. Frankly this incongruity scares me.
It's currently looking like being an ultra-optimizing Haskell backend - I don't quite have the time to get down to the C. Its still something I do want to do one day though...
If you can't squeeze yhi, you can always rewrite it. Yhc bytecode is the best documented Haskell IR in existance; it took me a week and ~8 kbytes to produce a (throwaway prototype) implementation of most of yhi in Intel assembly.
Also, the FFI is *mandatory* (Tom correct me), since all of Yhc's primops are pure (unlike GHC) - so FFI calls are the only way to perform IO. You might be able to revert to the nhc-ffi implementation, baking a set of allowable foreign functions into the interpreter. Also, gmp is bound using the FFI.
It is currently mandatory, but the intention was to move back to baked in operations for the things in interpreter. The initial reason for moving everything into FFI was to test the FFI out. Our hope is that the interpreter can be parameterised (using #define) to remove the dependence of libffi and libgmp, to result in a smaller binary and less portability concerns - although those two libraries would be the standard on a normal computer. Thanks Neil