Modification to foreign import/export

[Alastair Reid]

> > What does all this complexity buy us?
>
> The ability to specify #include files in a portable way,

Can this not be done with one small extension instead of a much larger general
purpose extension?

> If a Haskell implementation needs to know from which library to take
> which function, e.g. an interpreter using dlopen/dlsym, then again
> this must be specified somehow. We could invent a way to encode it in
> the foreign function name, but [...]

The ffi spec already has a way to specify this: list it with each ffi decl.
There's no need to invent anything new.
I'm looking for a compelling argument that the convenience of adding all these
extra declarations outweighs the costs of a more complex design, introducing
more keywords into the language, etc.

> When I import many stdcall functions, I must currently write stdcall
> with each declaration.

Can't you just add the required functionality (global library declarations,
global calling convention declarations, order-dependent overriding, etc.) to
hsc2hs?

> Why I should be require to wrap everything in C if the compiler can
> be designed to do that for me?

Why not write a preprocessor that turns ffi/Java into ffi/C?
Chances are that one of the existing calling conventions (i.e., stack and
register layouts) and the existing set of types is going to be a pretty good
fit.

If you find yourself using a Haskell implementation that runs on a JVM and want
to optimize it (e.g., support some Java types more directly), you can tweak
ffi/Java to generate native Java or marshall some types more intelligently or
whatever.

A compiler flag can turn this on or off.

> Surely maintaining just a C compiler is easier than maintaining both
> C and Haskell compilers. So what, abandon Haskell because using C
> for everything is simpler for compiler writers?

I'd describe what I want as follows:

  Keep the ffi standard simple so that:

  1) An already hairy piece of code doesn't become unmaintainable.

  2) Incompatabilities between different implementations can be kept to
     a minimum.

  And the way to achieve this is to put any proposed complexity in tools
  rather than in the ffi.

> > ps Could I propose that any proposed new keywords be prefixed by __
> > or ffi_ or something like that. [...]
>
> Of course they are not keywords in any context except foreign language
> declaration. That's why I wrote "pseudokeywords".

I hope you don't mean anything like Haskell 98's "as", "qualified" and "hiding"
special identifiers?  Those have to be one of the worst features in the entire
Haskell syntax.  Surely there's a better way?

--
Alastair Reid