Rationale of capi?

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