On 26-Feb-2001, malcolm-ffi@cs.york.ac.uk <malcolm-ffi@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 stronger.) -- Fergus Henderson <fjh@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.