On Sun, 2009-06-14 at 22:26 +0100, Neil Mitchell wrote: > Hi > > > 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. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
