Summary of current change suggestions

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Wed Feb 21 22:53:28 EST 2001


"Simon Marlow" <simonmar at microsoft.com> wrote,

> I've kept pretty quiet on this issue before, because I didn't have a
> strong view.  Now I'm concerned that some of the suggestions people are
> making would take the design in the wrong direction.  
> 
>    * specifying libraries in the source isn't the right way to
>      go.  Library names change independently of APIs, and can be
>      platform-specific.  
> 
>      This should be a compiler-specific feature: eg. GHC uses package
>      specifications to identify libraries.  Addtionally allowing
>      libraries to be specified in the source would just be a pain for
>      us.

Agreed.

>    * specifying include files in the source is fine; but I'm actually
>      quite happy to leave this to an external tool like hsc2hs
>      to sort out rather than adding extra syntax to the language,
>      but that's just me.  

A tool won't do.  With -O, GHC exports foreign calls into
interface files.  So, if you use a couple of libraries in
your application program, your program may suddenly dump
core just because a library imported some C stuff of which
you never heard before.  The include has to wander into the
.hi file together with the foreign function.

I just removed a handful bugs from Gtk+HS examples that were
caused by exactly this problem.

> If we really must add new syntax, let's
>      make it as general as possible to accomodate future design
>      enhancements.  I'd go with
> 
>           foreign decl cinclude "<foo/bar.h>"
> 
>      in other words,
> 	
> 	    foreign decl VARID [ STRING ]

I thought, the idea at the meeting was to handle extra
information for different languages uniformly.

Cheers,
Manuel




More information about the FFI mailing list