FFI Definition

[Sven Panne]

"Manuel M. T. Chakravarty" wrote:
> [loading dynamic libs problem]
> This is just like the library object specification that we have now also.

Huh? What? I've never seen a lib object spec... (or completely forgot it %-)

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

The callconv already prescribes the syntax of ext_ent and the typing, so
it could prescribe the possibilities for mode, too. And static/dynamic
makes sense e.g. for cplusplus and jvm at least, with a slight
reinterpretation of the actual meaning, but that's not very crucial.

I'm against stuffing everything into ext_ent in a string form, which would
mean a mini-language within Haskell (TCL is lurking! :-). My proposal:

   -- allowed for import/export
   mode     : 'static'    -- allowed for ccall/stdcall/cplusplus/jvm/..., default then
            | 'dynamic'   -- allowed for ccall/stdcall/cplusplus/jvm/...
            | 'interface' -- allowed for jvm
            | ...

And for legacy reasons we have to keep dynamic for some time, anyway.
 
> > Also should 'label' be there?  Doesn't make sense for Java, does it?
> 
> Hmm, not really.  So, also into `extent'...

But it *makes* sense for some calling conventions, and it the actual
translation will need the callconv (name mangling!), so the only change
I propose here is a comment:

   fkind    : 'import'
            | 'export'
            | 'label'    -- allowed for stdcall/ccall/cplusplus

Hmmm, looking at the whole foreign beast gives me a slightly uneasy
feeling now. There are loads of strongly interconnected side conditions,
but I fear we can't avoid this because of the complexity of the whole
topic. But at least we should strive for an ext_ent with minimum complexity
when we go the "special id" way, like we did in the past.

Another extreme route would be:

   topdecl  : 'foreign' string var '::' type

with a separate syntax for the string contents. Is there some "standard"
or at least widely accepted way of describing a multi-language FFI? We
could re-use this here, but I'm not aware of anything like this...

Cheers,
   Sven