FFI, safe vs unsafe

[Malcolm Wallace]

John Meacham <john at repetae.net> wrote:

> 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