On Fri, Apr 24, 2009 at 10:09 AM, Sam Martin <sam.mar...@geomerics.com> wrote: > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
