On 03-Jan-2001, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
Wed, 3 Jan 2001 21:44:03 +1100, Fergus Henderson <fjh@cs.mu.oz.au> pisze:
Personally I'd rather have a single well-designed convenient foreign language interface as a standard part of the language, rather than having a minimalistic foreign language interface in the language standard and having convenience provided by a separate tool (or by several competing separate tools). But I understand why you might differ on that point.
I would prefer that too if it was possible, but it does not look well. Interfacing to C is complex enough, it's yet worse for other languages.
A problem: HsFFI includes some C headers (stdint.h, which includes among others features.h on glibc). There are headers like stdio.h (if I remember correctly) which provide certain prototypes or macros only when certain macros are defined, like _XOPEN_SOURCE and _GNU_SOURCE. ... #option -optc-D_GNU_SOURCE -optc-D_XOPEN_SOURCE=500 #undef _GNU_SOURCE #define _GNU_SOURCE 1 #undef _XOPEN_SOURCE #define _XOPEN_SOURCE 500
Ugly, isn't it? ... Would a builtin support predict all possible uses of C features?
Well, the Mercury language specification doesn't say anything about compiler options, since they tend to vary between implementations. But with the Mercury build environment (a de facto standard, I suppose ;-), you can solve that problem by putting CFLAGS = -D_GNU_SOURCE -D_XOPEN_SOURCE=500 in your Mmakefile, or CFLAGS-foo = -D_GNU_SOURCE -D_XOPEN_SOURCE=500 if you only want it for module `foo'. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.