"Simon Marlow" <simonmar@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