FFI progress

[Manuel M. T. Chakravarty]

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

> Here's my contribution to re-invigoration:
> 
> As I recall the main sticking point is whether we have a global
> 'foreign library' declaration in addition to foreign import etc.
> The main (only?) motivation for such a thing is
> 
> 	C
> 
> It's a powerful motivation because C is ubiquitous.  I do have
> one suggestion to elaborate our earlier proposal.  To remind you
> our simple-minded proposal was
> 
> * no 'foreign library' decl
> * the c-language-specific string on a foreign import could say
> 	foreign import "gtk:foo" foo :: <type>
>   with 'gtk' indicating which foreign package was indicated
> 
> Main complaint was: the package-name => what-to-do mapping still isn't
> specified.  In short, our simple-minded proposal is too simple-minded to
> be useful.
> 
> OK so the new suggestion is this: the 'gtk' indicates 'please #include
> gtk.h'.
> It's up to you to have a 'gtk.h' lying around, in which you can put all
> the 
> other #includes (including whether in <> brackets or "" quotes) to your
> heart's content.
> 
> I bet this still doesn't solve the problem entirely, but maybe it solves
> enough
> of the problem.  I remain reluctant to generate elaborate designs for a
> single
> language.

I completely agree that we should have a simple solution and
achieve more convenient interfaces via the existing FFI
tools.

I propose the following (basically my last proposal plus
suggestions made by others):

  foreign import "gtk.h:foo" foo :: <type>

corresponds to a `#include "gtk.h"' and

  foreign import "<gtk.h>:foo" foo :: <type>

corresponds to a `#include <gtk.h>'.  The former allows to
have a custom `gtk.h' "lying around" as suggested above.
The filename may of course be a path.

As suggested by SimonM, we also allow multiple includes
seperated by comma

  foreign import "<sys/types.h>,<sys/sockets.h>:socket" socket :: <type>
  
(This could be solved by a custom header, too, but IMHO
allowing a list of headers doesn't complicate the
implementation much, but makes a common case more
convenient.)

foreign import/export modifiers like unsafe and dynamic can
be in arbitrary order (proposed by SimonPJ).

"foreign export dynamic" requires a result type of the form

  IO (FunPtr prim_type)

(proposed by Sven).

(Of course, concrete implemenatations - like the one in GHC
and nhc - may support the old syntax for backward
compatibility.)

Rationale
~~~~~~~~~
This is easy to implement and as close as possible to the
current syntax while still being better suited for multiple
languages.  It is not as flexible as the proposal from
Marcin and Malcolm, but significantly simpler.  More
sophisticated interfaces can be realised on top of the basic
FFI interface by tools.

Proposed decision procedure
~~~~~~~~~~~~~~~~~~~~~~~~~~~
I propose that if nobody can come up with an important
scenario that cannot be implemented with the above proposal,
we adopt the proposal.  (Here "cannot be implemented" means
technically infeasable, not less convenient.)

If we adopt the proposal, I will define it in detail.

Cheers,
Manuel