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