Binding to inline functions

[Simon Marlow]

Duncan Coutts wrote:
> On Tue, 2009-08-25 at 13:18 +0100, Simon Marlow wrote:
>> On 23/08/2009 20:34, Duncan Coutts wrote:
>>> On Sun, 2009-08-23 at 15:09 -0300, Maurí­cio CA wrote:
>>>> I understand we can't use 'foreign import ccall'
>>>> to wrap inline C functions. Do you think it could
>>>> be possible to have an option in cabal to generate
>>>> such functions in an object file when #included in
>>>> a C file, in a compiler independent, portable way?
>>> It might be better to include this feature into hsc2hs and/or c2hs
>>> (which may in turn require some help from Cabal).
>> I think it would be easy to do in GHC.  We already have the machinery to 
>> generate the _stub.c files and compile them.
>>
>> The main question is what the syntax should look like.  I was toying with
>>
>> foreign import capi "foo" foo :: ...
> 
> While maybe it can be done in ghc, is that the best place to put it? Do
> we do so without extending the FFI spec?
> 
> The advantage of using something like hsc2hs is that we can still
> compile the same code in hugs, nhc, jhc and uhc.

Yes, it could be done in hsc2hs.  I don't think the GHC build system or 
Cabal currently handles the _hsc.c stub files that hsc2hs produces (at 
least, if it does, I can't see where).  That can be fixed, of course.

So the reason I thought of adding it to GHC is because in a sense it's 
just another calling convention for the FFI to support.  If it was done 
in hsc2hs then the syntax becomes heavier - you need both a foreign 
import and an hsc2hs directive of some kind, compared to just a foreign 
import.  In c2hs the syntax could be lighter, but c2hs isn't widely 
available.

>> I wonder whether not being able to specify the actual calling convention 
>> will be a problem, however.  We are relying on the calling convention of 
>> foo being implicit.  Are there cases where this might cause a problem?
> 
> If we do it via hsc2hs or c2hs then there's no need to specify any
> calling convention. We just get the one declared in the header files.
> This means we can handle stdcall, ccall and even crazy platform-specific
> variations like __attribute__((regparam, 3)).

And the same would be true if it was done in GHC.  The point I failed to 
  make very well was that you don't get to declare the calling 
convention, so you rely on the header file supplying it.  Of course, if 
you do this in hsc2hs you could pick some syntax to declare the calling 
convention.  This is only a minor point.

> A generalisation of this is needed for calling "functions" defined by
> macros, and C varargs functions. A similar case, that is not fully
> automatic, is cases like binding functions that pass C structures by
> value. The "C structs by value" problem is already on the IHG wishlist.

I'm thinking of this as all part of the same thing: a "function" that 
can be "called" from C code by writing f(arg1, arg2, ...).  My 'foreign 
import capi' would let you call any of these, as would a hsc2hs extension.

Ok, I don't really mind where it's implemented, especially if someone 
else does the work :-)

For doing it in GHC:
   - lighter syntax
   - no extra build system or Cabal support necessary

For doing it in hsc2hs:
   - multiple compilers get to take advantage

Cheers,
	Simon