initial "foreign import prim" patches for review
duncan at well-typed.com
Mon Jun 15 05:33:46 EDT 2009
On Sun, 2009-06-14 at 22:26 +0100, Neil Mitchell wrote:
> > I've changed it to require -XGHCForeignImportPrim.
> The idea of naming a language feature with a compilers name seems like
> a bad idea - surely these extensions could possibly work in other
> compilers, for example LHC.
Normally that's the case, if it's a language feature then in principle
it could be implemented by any compiler. But this isn't just a language
feature, it's a compiler-specific calling convention. There is no
external specification of this calling convention, where as ccall and
stdcall are well specified.
It's a bit like hugs's (unnamed) extension
primitive primEqChar :: Char -> Char -> Bool
sure, the syntax could be re-used in LHC but the thing that lies beneath
it is completely specific to hugs.
Indeed supposing hugs switched to use:
foreign import prim "primEqChar" primEqChar :: Char -> Char -> Bool
then it becomes even more important that we do not mistake of for being
the same as what ghc uses, because the underlying stuff is completely
different and incompatible.
Perhaps it should be
foreign import ghcprim ...
foreign import hugsprim ...
just to make it really really clear that it's a compiler-specific
primitive calling convention.
There's nothing wrong with trying to specify these calling conventions
better, if they're going to be stable. For example ghc's prim may morph
into a more standard c-- calling convention in time, but that doesn't
take away from the fact that each compiler does (or at least could) have
its own fastest native calling convention.
I don't expect that the GHCForeignImportPrim extension will ever be
registered, indeed as a compiler-specific one it probably should not be.
This also effectively limits its use to the core libs distributed with
the compiler, which is probably also a good thing given that the
underlying mechanics are not guaranteed to be stable.
More information about the Cvs-ghc