On Wed, 2009-06-10 at 10:14 -0400, Isaac Dupree wrote: > Simon Marlow wrote: > > foreign import prim "has_side_effects commutable foo#" :: ... > > note, FFI spec defines lack-of-"safe/unsafe" to mean "safe" (and it's > *not* unsafe in the typical FFI ways, so I think that makes a bit more > sense to me than "unsafe")
Right, I've switched it round. > If there are features like "can_fail" and "has_side_effects" whose > absence leads to an optimization, it makes me a little uncomfortable > (what if they're not specified when they should be? didn't we have a bug > like that for has_side_effects just recently, even with the primops all > specified in one well-commented file?) So far this isn't a problem because the current patches treat these imported primops as if they were foreign calls at the Core level. So they're automatically treated with some suspicion by the optimiser. If/when we refactor the PrimOp and switch "foreign import prim" to desugar to PrimoOp in Core, then we would probably want to make the defaults safe. For example instead of "has_side_effects", that'd be the default unless specified otherwise, eg "has_side_no_effects". > Also would it be better to call it "ghcprim" rather than "prim" (then > people will be more wary of all these compiler-specific requirements), > or does it not really matter? I've changed it to require -XGHCForeignImportPrim. Note that hugs has had a similar syntax for ages (pre-dating the FFI): primitive primEqChar :: Char -> Char -> Bool Using the FFI syntax works reasonably well since it has a way to specify an external name string, and that string can include a bunch of other useful info, like these primop properties. Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
