Rationale of capi?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Rationale of capi?

Lauri Alanko
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


_______________________________________________
FFI mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ffi
Reply | Threaded
Open this post in threaded view
|

Re: Rationale of capi?

Ian Lynagh-2
On Sun, Oct 07, 2012 at 03:34:45PM +0300, Lauri Alanko wrote:
>
> In fact, function-like
> macros are (or should be) a rarity, since inline functions serve the
> same purpose better.
>
> So to me "capi" seems to buy very little, and it only supports
> strangely specific needs.

In theory, perhaps. In practice, at least one platform defining a
standard function with something like

    #define fopen fopen64

is common, and I think the standard explicitly allows many such
functions to be defined as macros. We certainly use capi a lot in the
standard libraries.


Thanks
Ian


_______________________________________________
FFI mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ffi