Modification to foreign import/export

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

Manuel writes:

> Summary of Open Points
> ~~~~~~~~~~~~~~~~~~~~~~
> 
> - Language specifiers: Other names for "ccall" (possibly, "c")
>   and "stdcall".

I'm not totally convinced that a change from "ccall" to "c"
is justified.  In fact, the foreign language could be anything at
all - mercury, perl, c++ - the specification merely says that its
call stack discipline looks identical to the standard C discipline.
So to call it just plain 'C' might be misleading, and the current
'ccall' might be a more accurate description.

> - Header files: Syntax for specifying a header in case of a
>   foreign declaration for C.

I would opt for a specification of header/link-library that remains
separate from the current foreign decls, to avoid having to repeat
the details many times.

> - Only one foreign language per Haskell module?

Yes, I think this is a reasonable restriction for the moment.  However,
if the foreign import decls always have a language specifier, we
could easily allow, for instance

    foreign library C    "<ncurses/curses.h>" "-lcurses"
    foreign library java "blah" "blah"

    foreign import C    "curses_function" cf :: Int -> IO Int
    foreign import java "java.blah.*/foo" jf :: Int -> IO Int

and it remains clear how each function should be compiled and linked.
At least, if we adopt the restriction to one foreign language per
Haskell module now, we should leave open the possibility of removing
the restriction in future without breaking any existing code.

> - Global specification of parameters such as the foreign
>   language, dynamic library to be loaded, and header file to
>   be included?

Yes, I think we need it.  I can't think of any particularly nice
syntax for it though.

Regards,
    Malcolm