Modified proposal for default decls
fjh at cs.mu.oz.au
Mon Feb 26 12:03:45 EST 2001
On 26-Feb-2001, malcolm-ffi at cs.york.ac.uk <malcolm-ffi at cs.york.ac.uk> wrote:
> > What is particularly tanatlising is that to a first approximation none
> > of this is necessary. For example, the native code generator is quite
> > happy without any of the new stuff now proposed.
> So, because one system is clean and clever and doesn't need all this
> junk, all the other systems should simply suffer for their ignorant
> poverty? :-)
The reason that the system in question (ghc's native code compiler)
doesn't need all that junk is not that it is clever, rather it is that
it only supports an impoverished interface. The Mercury native code
generator does use the C header file names, for typechecking C imports
and for interfacing with C macros. Likewise the Mercury .NET code
generator's C++ interface does the same. Typechecking C imports and
interfacing with C macros are both very useful features, and if ghc
wasn't so lame ;-), it would support those features, and then it would
need the C header file names too.
<grinning, ducking, and running for cover> ;-)
> > c) What is necessary for particular compilers, compiling in a particular
> > way, to generate the right code.
> > Therefore we propose that (c) be not part of the FFI standard.
> In that case, I'd like you to be completely consistent and remove
> 'unsafe' from the FFI spec. nhc98 and Hugs don't need it, so other
> compilers shouldn't need it either!
The Mercury compiler has an attribute `will_not_call_mercury',
which I believe is analagous to ghc's `unsafe' attribute.
So ghc is not entirely alone here. (Furthermore, AFAIK these
two instances evolved independently, rather than either being
influenced by the other, which makes the case for such an attribute
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
More information about the FFI