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

[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.

>      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 am not sure if you read it, but there has been _a lot_ of discussion
about FFI annotations in the concurrency threads. 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.



> 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.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈