Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Fri Dec 1 14:50:02 EST 2000
Fri, 1 Dec 2000 14:45:32 +0000, malcolm-ffi at cs.york.ac.uk <malcolm-ffi at cs.york.ac.uk> pisze:
> Of course hsc2hs does more than just filling in constants, but for
> just that one task, I wonder if we should be extending the primitive
> FFI mechanism itself.
I once proposed something which is related to ghc's _casm_ as foreign
import is related to _ccall_. AFAIR nobody seemed interested.
C macros with parameters are harder than constants. What is worse:
sometimes it is not clearly documented whether a function provided
by a library is really a function or can be also a macro.
There is a fundamental difference between functions and variables on
one side, and macros, enum constants and struct fields on the other.
Using objects of the first kind does not require cooperation with a C
compiler. Everything needed to use the object are determined by the
official interface. A programmer writes a foreign declaration which
matches the documentation and it's fine.
OTOH the details for the second kind are hidden in C headers and may
differ between versions of the library.
Current foreign declarations support only the first kind. They are
implementable in a native code generator. They are even independent
of the language, provided that names are not mangled, types are
compatible and the calling convention is supported.
Approaching the second kind in the core language is tricky. First of
all, it must be somehow defined which C headers to include to find
a definition, and what preprocessor symbols to #define to make it
available. Don't forget about specifying which C compiler to use and
with which options, e.g. which include paths. The whole thing is more
language specific than foreign declarations for the first kind.
There are two separate issues:
1. Is it possible to have the second kind from the level of the
Haskell compiler at all (done in an sufficiently elegant way to
think about it as a candidate proposal for the official FFI)?
2. If so, which features are worth supporting? Perhaps we could
completely get rid of an equivalent of hsc2hs.
We could dream about fantastic features for the second question,
but it's worth nothing if the answer to the first one is NO.
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTÊPCZA
More information about the FFI