FFI proposal: allow some control over the scope of C header
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon May 8 17:50:47 EDT 2006
> Manuel M T Chakravarty <chak at cse.unsw.edu.au> wrote:
> > This leaves me with the opinion that we should really leave this as
> > pragma and not make it into FFI syntax. It's a hint to some
> > implementations and irrelevant to others.
> Ah well, if we use that eminently sensible criterion, then the
> "safe/unsafe" annotation on foreign imports ought to be in a pragma too.
> For some implementations (yhc/nhc98) it is simply irrelevant, it is
> really a ghc-ism. :-)
I think safe/unsafe is more fundamental for two reasons:
1. nhc currently has it easier than GHC as it doesn't support
concurrency. Although, we didn't provide an explicit features
for concurrency in the FFI addendum, we tried to co-exist.
2. safe/unsafe is about enabling an optimisation. Implementations
are of course free to not apply that optimisation, and then they
don't care about the annotation. So the real question is, if
nhc would want to achieve the same level of performance as GHC,
could it still ignore the annotation?
So, I guess, I need to refine my criterion: We leave an annotation as a
pragma if it is a hint to some implementation and irrelevant to others
that can ignore achieve comparable levels of performance while ignoring
it. (Strictly speaking, I guess there is still an exception if it is
generally *much* easier to achieve good performance when taking the
annotation into account.)
More information about the Haskell-prime