Modification to foreign import/export

[Alastair Reid]

> This has the advantage that when the library name is #ifdefed, the
> conditional needs not to be repeated for each function. Similarly
> for #included header names.

Note that this can be done without separating the library name from the ffi
decl:

#ifdef UNIX
# define LIBNAME "foo.so"
#else
# define LIBNAME "foo.dll"
#endif

foreign import ... LIBNAME ...
foreign import ... LIBNAME ...
foreign import ... LIBNAME ...

> [...] if more than one library is specified,
> an interpreter can try each of them for each function.

Of course the error messages will be more confusing than they need to be...

(This is true for both compilers and interpreters though the confusion is worse
for interpreters because they try harder to hide the programmer from the
complexity of the underlying system.)

> We can give up the irrelevance of the order of declarations (which does
> not apply for regular imports anyway - they must be at the top of the
> module, before all local definitions). We can have some declaration
> specifying the context of *following* foreign declarations. Another
> such declaration can change the context later in the module.

Just to be clear that I understand this argument, you're saying that:

  It is ok to severely break order independence in the ffi because it is
  already mildly broken in normal module import?

This is just another source of confusion for the baffled programmer.
(And more clutter for a language that already needs to go on a diet.)

I'd say this is quite a bit worse than order dependencies in import decls
because if they try to put an import decl in the middle of a module, they get a
syntax error but if they put library decls out of order, they get a linking
error (harder to understand) or they get the wrong symbol which probably has
the wrong type and leads to a segmentation fault when they run it.

Let's fix module import instead.

> Here is a concrete proposal:
> [proposal deleted]

Looks like a massive extension to the ffi definition.
What does all this complexity buy us?

Wouldn't it be better to fix on a C/Pascal-like interface on the Haskell side
and implement a series of similar ffi's for Java, C++, etc. which also target a
C/Pascal-like interface?  Now if I want to call Java code, I use ffi/Java to
construct C-like exports for the Java library and I use ffi/Haskell to generate
C-like imports for the Haskell library.

On the plus side, this style of narrow-waisted architecture is much, much
easier to maintain, concentrates debugging/development effort on just one
interface, provides utility to people on both sides of the interface (because a
C++ programmer could use the exports from the Java library too), is simpler, is
more flexible, ...

Could someone summarise the minus side for me?  I think I missed the motivation
for extending the ffi to support other languages.

--
Alastair Reid

ps Could I propose that any proposed new keywords be prefixed by __ or ffi_ or
something like that.  Adding keywords like "library" (i.e., ordinary useful
words that programmers might already be using as variable names) breaks a lot
of code.