Summary of current change suggestions

[Simon Peyton-Jones]

I must say that I like Manuel's proposal below.  I'm a bit alarmed
about the proliferation of features in the FFI, but Manuel's story
makes it seem more tractable.  It's in the spirit of putting all
the language-specific info needed for a particular foreign import
into a single string.  

The FFI spec should have a section specifying the syntax of this
string for a selection of languages.

Incidentally, we should make the order of 'import/export' , 'dynamic',
'unsafe' keywords arbitrary.  So you should be able to write
	foreign import unsafe dynamic ...
or
	foreign import dynamic unsafe  ...

I'm not sure exactly which the unordered set should be, maybe
the optional components.

Simon

| I am still against cpp, but maybe we can relegate defaults
| to the tools domain in general (and whoever is fond of cpp,
| can use cpp).  Without defaults, it is still possible to use
| all features of the FFI.  If a user wants the convenience of
| defaults, she has to use a tool (as with all the other
| "features" that we considered too heavy for the core FFI).
| 
| Then, we could use the following general form of foreign
| imports:
| 
|   foreign import [callconv] [funname] ['unsafe'] varid :: prim_type
| 
| where funname is calling-convention dependent and in the
| case of ccall is either merely the name of the imported
| symbol or an include specification followed by a colon and,
| then, the imported symbol.  So, we have
| 
|   foreign import ccall "gtk_window_new" 
|     windowNew :: CInt -> IO (Ptr Window)
| 
| or
| 
|   foreign import ccall "<gtk/gtk.h>:gtk_window_new" 
|     windowNew :: CInt -> IO (Ptr Window)
| 
| If the <.> are omitted in the include specification, it
| corresponds to an #include"...".