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
> 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
> * 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.
More information about the FFI