Again: FFI syntax

[Sven Panne]

It's weekend and so it's time for a new syntax proposal...  :-)

After the recent clarification of the role of "import" and "export" and
a few other suggestions, here's my next shot:

------------------------------------------------------------------------
topdecl  : 'foreign' impexp callconv extent var '::' type

impexp   : 'import'
         | 'export'

callconv : <empty>            -- defaulting to 'ccall'
         | 'ccall'
         | 'stdcall'
         | 'cplusplus'
         | 'jvm'
         | 'dotnet'

extent   : string             -- Wake this optional? Which default then?
------------------------------------------------------------------------
Syntax for ccall/stdcall's import extent:

extent   : 'static' safety cid include   -- former f.i.
         | 'dynimp' safety               -- former f.i.d.
         | 'dynexp'                      -- former f.e.d.
         | '&'             cid include   -- former f.l.

safety   : <empty>
         | '!'               -- means "never re-enters Haskell world"

include  : <empty>
         | '<' <anything but '>'>* '>'
         | <anything but '<'> <anything>*
------------------------------------------------------------------------
Syntax for ccall/stdcall's export extent:

extent   : cid
------------------------------------------------------------------------

I don't have very strong feelings about other names for "dynimp"/"dynexp",
so I'll leave this to the native speakers.

An open point is the last case of the include production: Should we
implicitly wrap double quotes around it or not? I don't really like
such implicit things, but

    foreign import ccall "static !myproc \"myinclude.h\"" myProc :: ...

could look a little bit funny because of the backslashes. Again, I don't
really mind about that topic. But I'm against implicitly suffixing with
'.h' in any case.

The story above has a few advantages compared to the last proposal:

   * import/export explicitly tell you (= the compiler :-) if a new
     Haskell name is introduced or not, without inspecting extent.

   * Silly combinations like "an unsafe label" or "a dynamic import with
     a given C-name" don't exist.

   * It's (hopefully) more mnemonic, e.g. '&' reminds one of the C address-of
     operator, and '!' suggests something inherently dangerous.

Comments? We should really come to an agreement on the syntax soon...

Cheers,
   Sven