Summary of current change suggestions
malcolm-ffi at cs.york.ac.uk
malcolm-ffi at cs.york.ac.uk
Tue Feb 20 13:54:05 EST 2001
Ok FFI folks,
I think we're all agreed now on the desirability of tweaking the FFI
(a) arbitrary new foreign languages to be added;
(b) the "foreignname" specifier to be (potentially) richer, depending
on the particular foreign language in question;
(c) abstraction of common header/linklib information to a single
new sort of decl.
For backwards compatibility, I suppose on (b) we are going to have
to continue to allow double-string specifiers of the form
foreign import "linklib" "cname" hname :: type
for some time, although that form would be deprecated from now on?
We know mostly what the richer form of the "foreignname" specifier
will be for Java, and in any case we can leave that design to SPJ+EM.
However, we have also heard one or two half-hearted suggestions to
enrich the "foreignname" string for C as well. For instance, Manuel
suggested "Gtk: gtk_new_window". Is anyone convinced that this
is a good route for C, or should we settle instead on getting (c)
right, leaving the "foreignname" untouched for now?
As far as (a) is concerned, we have three decisions to make:
(1) Do we use quotes around the language name or accept a simple
varid? E.g. "java" vs java. As Marcin points out, the names
of the languages C and C++ are not varids, so would need to
be enclosed in quotes. On the other hand, see decision point
(2) The actual names for languages or calling conventions. Manuel
suggests a change from naming the calling convention to naming
the foreign language. This is somewhat attractive. However,
I think many languages have a simple C-callable interface and
we don't need to know anything more about the actual language.
If this is true, I think we should continue to name the calling
convention rather than the language. Hence, the names ccall
and stdcall might be retained, java can be added. If anyone
actually comes up with a C++ binding, a name like cplusplus
(for instance) seems good enough to me. This also has the
advantage of backwards compatibility, which incidentally would
force decision point (1) above towards no-quotes.
Incidentally, the intention would _not_ be that all compilers
must support all foreign languages. As at present, only
the ccall convention is mandatory. Any other named calling
convention should be parsed, but if the compiler doesn't support
it, a warning (at least) should be issued. In that situation,
it is unclear whether the compiler can actually generate sensible
code. (At the moment, I think the FFI standard says if your
platform doesn't support stdcall, code should default to ccall?
Obviously that doesn't scale well to java for instance!)
(3) Where do we allow the language specifier? In my opinion,
definitely in foreign import and export decls. This is at
minimum for backwards compatibility, but looking forward to the
day when someone writes FFI code for more than one language in
the same module (eek!), it will be needed there. For the same
reason, I would argue that it belongs in the new kind of decl
required for (c).
Now how do we tackle the biggest change, issue (c): abstraction of
common header/linklib information to a single new sort of decl?
Disregarding syntax for the moment, Marcin has suggested a concrete
design that conflicts in some ways with backwards compatibility:
* the primary specification is of the language not the calling convention
* the calling convention is defined as only one attribute of a language
* the calling convention is mandatorily removed from its current position
in all functions
His proposal also adds many of the features that we want:
* names of include files
* names of link libraries
* decl appears once and scopes over all foreign functions in that module
* it is not language specific: the attribute-based style allows new
languages to have attributes we haven't even thought of yet.
and some features that might be nice additions:
* the global decl can be overridden for a single function
* using an attribute style directly in the existing foreign import/export
decls is potentially cleaner, as it can tidy up current blots like
'unsafe', and admits the possibility of needing further ad-hoc
specifications in the future. (Didn't someone have an example
that involved blocking/non-blocking thread-safety?)
Since I believe backward compatibility is very important, would
anyone like to either modify Marcin's proposal, or make a new concrete
proposal that is perhaps slightly more conservative but still achieves
I suppose backwards compatibility might not be entirely possible.
If it isn't, then we have a choice between making the changes as
small as possible (to make porting old code easier), or making them
as radical as possible (to ensure that the design is really clean
More information about the FFI