Modification to foreign import/export
reid at cs.utah.edu
Mon Feb 12 13:39:12 EST 2001
> > 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
> 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
> 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
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
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
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?
More information about the FFI