Hello. GHC 7.6 now supports a "capi" calling convention which allows "function-like" macros to be invoked from Haskell code with "foreign import". To me this seems like rather odd design. The advantage of pure ABI-level FFI specifications (the standard Haskell FFI) is that wrappers can be generated in pure assembly by the Haskell compiler itself and there is no dependence on the C language. In contrast, "capi" requires the wrapper to be produced by a C compiler since the wrapped macro can expand to an arbitrary C expression. My question is: if the Haskell compiler is to support FFI wrappers that require a C compiler, why then are the wrappers so limited in functionality? The "capi" calling convention only supports function-like macros, i.e. ones that take expression arguments and expand into an expression. But there are many other kinds of macros, too: ones whose arguments are types or identifiers, and that may expand into a declaration or a statement. In fact, function-like macros are (or should be) a rarity, since inline functions serve the same purpose better. So when a well-designed C API has public macros, these macros are usually _not_ function-like. But using these from Haskell still requires writing some wrapper C functions (or, now, wrapper macros!) manually. Not a big deal, but then again, writing wrappers in C for function-like macros wasn't a big deal previously, either. So to me "capi" seems to buy very little, and it only supports strangely specific needs. If a Haskell implementation is to support FFI wrappers that must be compiled via C, a much more general solution would have been to allow arbitrary inline C code (instead of just the name of a macro) in the definition of the wrapper. I can't see that costing much more than the current design, and its benefits seem much greater. So am I missing something here? Lauri