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. * 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. 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 ] Cheers, Simon
* specifying libraries in the source isn't the right way to go. Library names change independently of APIs, and can be platform-specific.
I like the high level goal this is heading towards and was in complete agreement with implementing it in rules like this until.... I realised that all that Hugs sees is the source (i.e., there's no makefile to put extra compilation info into) - so if it ain't in the source, where is it? But I like the rule... Alastair
"Alastair Reid" <reid@cs.utah.edu> wrote,
* specifying libraries in the source isn't the right way to go. Library names change independently of APIs, and can be platform-specific.
I like the high level goal this is heading towards and was in complete agreement with implementing it in rules like this until.... I realised that all that Hugs sees is the source (i.e., there's no makefile to put extra compilation info into) - so if it ain't in the source, where is it?
Command line options passed to Hugs on startup, or possibly with :set. The former can be used to code the startup of Hugs including the correct options in a Makefile or shell script. (That's how I started doing it with GHCi - works fine.) As I have explained in an earlier message, putting libraries into the source just isn't going to work in all cases - eg, it won't work for Gtk+HS, because GTK+ wants you to execute a shell script (gtk-config) to determine the libraries. This is easy to do in a Makefile or script, but impossible in the source. Cheers, Manuel
"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
participants (3)
-
Alastair Reid -
Manuel M. T. Chakravarty -
Simon Marlow