FFI proposal: allow some control over the scope of C header files

Manuel M T Chakravarty chak at cse.unsw.edu.au
Mon May 8 17:50:47 EDT 2006

Malcolm Wallace:
> 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 mailing list