"Simon Peyton-Jones" <simonpj@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