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

[Manuel M T Chakravarty]

John Meacham:
> On Mon, May 08, 2006 at 05:50:47PM -0400, Manuel M T Chakravarty wrote:
> >      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.
> 
> actually, I believe all haskell implementations already have or are
> working on concurrency. I know Einar is pretty close to adding support
> to jhc, yhc has it, and hugs has a lot of the framework done so it
> shouldn't be too hard to bring it all the way.

Excellent.

> >      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?
> 
> Also, at some point "optimization" problems become correctness ones if
> they are vital for getting usable performance.

I agree.

> I am not sure if you read it, but there has been _a lot_ of discussion
> about FFI annotations in the concurrency threads. 

Yes, I saw that.

> there is a basic
> summary of our results on the Concurrency page on the wiki. the basic
> consensus is to drop the ghc-specific safe vs unsafe and annotate ffi
> calls with what your actual intent is. as in 'nonreentrant' if the code
> doesn't call back into haskell and 'concurrent' if the haskell runtime
> needs to arrange to run concurrently with it. the exact names and
> defaults are still being worked out, but I think we have a good
> consensus on at least what different annotations we need in order to
> give compilers of all sorts of implementation models exactly what info
> they need.

That's great.  The current FFI standard stayed away from concurrency, as
there was no concurrency standard, but now that we get one, the FFI has
to synchronise with that.

> > 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.)
> 
> it is fuzzy. some programs rely on NOINLINE for correctness, but of
> course they are making all sorts of assumptions about the underlying
> implementation so it isn't really portable anyway. for instance the
> NOINLINE unsafePerformIO newIORef trick for global state just doesn't
> work on jhc and it would be quite tricky to make it otherwise. Not that
> this is a new or particularly pressing issue as we will eventually hash
> everything out.

IMHO, NOINLINE unsafePerformIO newIORef is outside anything guaranteed
to work by our current standards.  Hence, programs that rely on NOINLINE
for correctness are bad programs - maybe useful, but bad!  So, jhc is
perfectly alright in that respect.  I wish we had a nicer alternative
for this dangerous idiom...

Manuel