Summary of current change suggestions

[malcolm-ffi at cs.york.ac.uk]

Ok FFI folks,

I think we're all agreed now on the desirability of tweaking the FFI
to permit

  (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) below.

  (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
our goals?

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
and extensible).

Regards,
    Malcolm