John Meacham
It would be nice if we can deprecate the not very informative 'safe' and 'unsafe' names and use more descriptive ones that tell you what is actually allowed.
Yes. I have always found that naming convention confusing and non-declarative. "Safe" means that the foreign call is unsafe, so please can the compiler do some extra work to make it safe. Rather than declaring the nature of the foreign function, it is an imperative instruction to the runtime system. (Likewise "unsafe", which means the foreign call is safe, so please tell the compiler to omit the extra safety checking.)
'reentrant' - routine might call back into the haskell run-time 'blockable' - routine might block indefinitly
These are indeed more descriptive, and I do hope we don't get the sense inverted with these terms. I would be in favour of adding them to the FFI spec, and deprecating the "safe" and "unsafe" terms. Do you have a suggestion for replacing "unsafe"?
'reentrant_tail' - will tail call a haskell routine 'reentrant_nonglobal' - will only call arguments passed to it. 'fatal' - routine always aborts or performs a non-local return 'cheap' - routine is cheap to call, may be duplicated freely by optimizer 'speculatable' - routine may be reordered and called speculatively, even if the optimizer can't prove it will eventually be used
I don't see any need to standardise these extra terms - as you say, they feel more like pragmas, and may well be meaningless for many compilers. Regards, Malcolm