| I propose the following (basically my last proposal plus | suggestions made by others): | | foreign import "gtk.h:foo" foo :: <type> | | corresponds to a `#include "gtk.h"' and | | foreign import "<gtk.h>:foo" foo :: <type> | | corresponds to a `#include <gtk.h>'. The former allows to | have a custom `gtk.h' "lying around" as suggested above. | The filename may of course be a path. | | As suggested by SimonM, we also allow multiple includes | seperated by comma | | foreign import "<sys/types.h>,<sys/sockets.h>:socket" | socket :: <type> Do we really need this? Surely it's not so hard to have one header file per package living in a standard place that collects the headers needed for a particular package, including whether they are <..> or "...", etc. Its easy to add features and nigh impossible to remove them. I suggest we have just "gtk:foo" (no ".h") meaning #include "gtk.h" Now we can sensibly interpret "gtk:foo" as meaning "foo from package gtk"; and in concrete terms import a suitable header file. But I could imagine a clever compiler could also use to add gtk.a to the link line etc (hence no .h). Let's see if simplicity is too painful. I can't imagine it will be. Simon