Most notably, Malcolm's latest proposal introduces a new form of abstraction (named thing), a bundle of attributes like Gtk or Bzip. Another environment for the compiler to manage! Soon people will want to export these things and import them elsewhere! This way lies madness.
Ok, so it was a bit of a wild idea. I quite like it, but I recognise that it is kind of elaborate and may be a step too far at the moment. I'm not so much bothered about whether we have a complicated 'foreign default' thing or not. In fact, I'm only really personally interested in being able to specify header files correctly - the very thing you propose to exclude!
What is particularly tanatlising is that to a first approximation none of this is necessary. For example, the native code generator is quite happy without any of the new stuff now proposed.
So, because one system is clean and clever and doesn't need all this junk, all the other systems should simply suffer for their ignorant poverty? :-)
c) What is necessary for particular compilers, compiling in a particular way, to generate the right code.
Therefore we propose that (c) be not part of the FFI standard.
In that case, I'd like you to be completely consistent and remove 'unsafe' from the FFI spec. nhc98 and Hugs don't need it, so other compilers shouldn't need it either! Make it a compile-time option to GHC, but please don't allow it in the source code. It is a compiler-specific option intended *only* to help GHC generate the right code, and doesn't belong in the standard spec. Well, I'm not serious, but you have to admit that it _is_ the logical conclusion of your approach.
Notice that c) is essential, but extremely language and compiler specific
I disagree - while it is certainly essential, there is no need for it to be compiler specific. That was the whole point of having this discussion - to establish a standard mechanism.
* The "gtk:" part is a concession to (b). It specifies a C package from which this procedure comes. There is then some compiler-specific mechanism for mapping the name of a C package to the location of its header files and .o file.
How does this idea of mapping from a "package name" like "gtk:" to a bunch of header and object files differ from the suggestion that we be explicit in the source code about that mapping with a 'foreign library' decl? You say it _should_ be compiler-specific: but why? That will really cause grief to users who are trying to write portable code. And besides, do any compilers currently have _any_ mechanism to map "gtk:" onto for instance #include <glib/glib.h> #include <gtk/gtk.h> #include <gtk/gtk_extra.h> ? No? I thought not. So why not let's try to develop a common mechanism that will work with all compilers?
You may think this is too minimalist, but there are big advantage to simple, minimal designs, even if they can't cope with every single case.
My worry is that it cannot cope well with the common case. Don't get me wrong - I like minimalism. But my feeling is that punting the 'difficult' stuff off into non-standard compiler-specific extensions is the opposite of minimal: users who want portability will end up needing to learn three different mechanisms, not one. Regards, Malcolm