On Fri, Apr 24, 2009 at 10:09 AM, Sam Martin
Thanks Bulat and Miguel.
Unless I've missed something, the FFI is an great description of how to bind C and Haskell - I think it's fine. I've read most of the content either on or referenced by the wiki - although I could well be missing something. I believe the problem is with the actual code compilation itself.
I need a list of .c and .h files as an end result of the Haskell compilation stage. I expect these c files will need to include Haskell runtime C code to operate, and therefore have some dependencies in order to compile and link.
Afaict, GHC as it stands does not allow me to do this, even though it presumably generates C in the process of compiling binary objects.
Actually having C source as an end result is critical as I need control over exactly how the source is compiled and linked. For example: - I need to compile to different targets: either a static C lib, exe, dll or C++ lib. - I need to support multiple compilers. - I might want to produce a custom runtime.
In short, I'd like to use Haskell as a code-generator.
I can't see that this would be unachievable, particularly given it's generating C already. Have I missed something?
You might have better luck with a different Haskell compiler. For example, JHC/LHC try to generate ansi-C and then compile that. YHC has a very hackable backend, see for the example the YHC-javascript backend. Jason