FFI Definition

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Sun May 6 10:14:32 EDT 2001


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

> "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 %-)

Like so

  foreign import ccall "libgtk.so" "gtk_widget_destroy"
    gtk_widget_destroy :: Addr -> IO ()

> > [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
>             | ...

The current idea is to make the syntax of the FFI extension
independent of the supported languages.  This requires to
stuff everything into `extent'.  Sure, this will make the
`extent' string complex for some languages, but that's
inevitable for anything but C anyway.  The old design really
benefitted from that we basically considered C only.  The
goal now is to bring the whole thing into better shape for
supporting multiple languages and being open for addition of
new calling conventions later.

> And for legacy reasons we have to keep dynamic for some time, anyway.

Let's forget about the legacy stuff for the FFI definition.
The systems have to support the legacy syntax, but that's
really of no concern for the definition.

> > > 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.

The other design, which I believe is cleaner (and which I
understand as the consensus at the HIM meeting), is to get
rid of all the side conditions and put all the calling
convention dependent stuff into `extent'.  The latter is
calling convention dependent and complicated (for everything
but C) anyway.  So, let's at least keep the rest simple.

In fact, any system supporting a calling convention like
jvm, will have to have a parser for extent strings anyway.

> Another extreme route would be:
> 
>    topdecl  : 'foreign' string var '::' type
> 
> with a separate syntax for the string contents. 

Yes that's going into the right direction, but it makes
sense to leave both the calling convention as well as
import/export out of the string.  The calling convention
defines which parser to use in the string.  That's good for
implementers, because then, the parser can be chosen before
parsing starts.  The import/export information is needed by
the name analysis, which we better leave independent of the
whole extent mess.

In other words, having the calling convention and
import/export seperate facilitates more modular compiler
support. 

Cheers,
Manuel




More information about the FFI mailing list