
Isaac Jones wrote:
Ross Paterson
writes: The initial version of the infrastructure may not support cpp, but it should appear later.
FWIW, I think it'll be one of the first things we do after the 0.1 release. Should be very easy with hscpp.
I would be very happy if 0.1 included (hs)cpp support, otherwise the infrastructure would be useless for me. :-( My OpenGL/GLUT binding depends heavily on preprocessing being available, for three reasons: * I need a mapping from some C types to the corresponding Haskell types, which is figured out by autoconf/configure for the target platform in question. Alas, Foreign.C.Types doesn't cover every C API in the world... * The calling convention for WinDoze DLLs differs when compared to the convention used for the same library on (any?) other platform. (great idea, Bill! :-}. This has to be mirrored in the FFI declarations. Duplicating hundreds of essentially the same declarations is not really an option. * Sometimes a preprocessor is quite handy for syntactic abstractions, e.g. a single OpenGL extension gives rise to 3 Haskell declarations, including one `foreign import "wrapper"'. Not using an abstraction here would replicate the knowledge how extensions are handled into dozens of modules => extremely bad. One tricky macro is a small price to pay to avoid redundancy and improve modularity. Cheers, S.