FFI Definition

[Manuel M. T. Chakravarty]

malcolm-ffi at cs.york.ac.uk wrote,

> This document looks like a very good starting point.
> 
>   * An omission: 'foreign label'.

Oops.

>   * Perhaps the 'specialid' production should contain all the calling
>     convention identifiers?

Yes, I had a weird idea here, but realise now that it
doesn't work anyway.

qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,

> Your syntax puts modifiers between the calling convention and the
> external id. I agree that it's consistent. Currently ghc accepts
> unsafe only between the external id and the Haskell id, and dynamic
> only instead the external id.

Yes, the idea was that this has to be changed in GHC.

Sven Panne <Sven.Panne at informatik.uni-muenchen.de> wrote,

>  * Because of the reason stated above, I think static/dynamic  *must*
>    come first after import/export, but the order of unsafe/safe,
>    callconv, and extent should not matter. The var (*not* varid, it was
>    a design flaw IMHO)

I agree.

>  must be the last thing before the colon,
>    otherwise it tends to drown in the syntax. 

Yes.

>  * I don't understand the last part of section 3.2.1, mentioning the
>    loading of dynamically loaded libs. Is something like dlopen() meant
>    here or linking against a libfoo.so? And the details of how/when this
>    linking should be done are completely obscure to me.

This is just like the library object specification that we
have now also.

"Simon Peyton-Jones" <simonpj at microsoft.com> wrote,

> | >         language specific stuff inside the "..." string
> | >         language independent stuff outside
> | 
> | But static/dynamic probably means different things, depending 
> | on the callconv.
> 
> I think it's arguable that static/dynamic should be inside the ext_ent
> string.  Indeed, one might use static/dynamic for ccall, and
> virtual/non-virtual/static for Java, etc.  "Baking in" static/dynamic
> for all languages may be inappropriate.
> 
> Nevertheless, you propose keeping 'mode' outside the ext_ent string.
> Why?  (Apart from backward compat.)

Meanwhile, I think, you are right, we cannot make a clean
language-independent static/dynamic distinction.

> Also should 'label' be there?  Doesn't make sense for Java, does it?

Hmm, not really.  So, also into `extent'...

"Simon Marlow" <simonmar at microsoft.com> wrote,

> A totally minor point, but 'wincall' doesn't feel right.  This
> alternative calling convention has been around since long before windows
> (it's always been the default calling convention for Pascal, I think).
> 
> I'd stick with 'stdcall' because that's what everyone else seems to call
> it.  gcc has a 'stdcall' function attribute, BTW.

Ok - so who prefers `stdcall' and who something else.

BTW, I have only included C++ for the sake of completeness
into the calling conventions.  As nobody is actively working
on this - or is there? - I am quite happy to not define
anything about it, but the name of the calling convention.
Better no definition than an untested one.

Cheers,
Manuel