Ok FFI folks, I think we're all agreed now on the desirability of tweaking the FFI to permit (a) arbitrary new foreign languages to be added; (b) the "foreignname" specifier to be (potentially) richer, depending on the particular foreign language in question; (c) abstraction of common header/linklib information to a single new sort of decl. For backwards compatibility, I suppose on (b) we are going to have to continue to allow double-string specifiers of the form foreign import "linklib" "cname" hname :: type for some time, although that form would be deprecated from now on? We know mostly what the richer form of the "foreignname" specifier will be for Java, and in any case we can leave that design to SPJ+EM. However, we have also heard one or two half-hearted suggestions to enrich the "foreignname" string for C as well. For instance, Manuel suggested "Gtk: gtk_new_window". Is anyone convinced that this is a good route for C, or should we settle instead on getting (c) right, leaving the "foreignname" untouched for now? As far as (a) is concerned, we have three decisions to make: (1) Do we use quotes around the language name or accept a simple varid? E.g. "java" vs java. As Marcin points out, the names of the languages C and C++ are not varids, so would need to be enclosed in quotes. On the other hand, see decision point (2) below. (2) The actual names for languages or calling conventions. Manuel suggests a change from naming the calling convention to naming the foreign language. This is somewhat attractive. However, I think many languages have a simple C-callable interface and we don't need to know anything more about the actual language. If this is true, I think we should continue to name the calling convention rather than the language. Hence, the names ccall and stdcall might be retained, java can be added. If anyone actually comes up with a C++ binding, a name like cplusplus (for instance) seems good enough to me. This also has the advantage of backwards compatibility, which incidentally would force decision point (1) above towards no-quotes. Incidentally, the intention would _not_ be that all compilers must support all foreign languages. As at present, only the ccall convention is mandatory. Any other named calling convention should be parsed, but if the compiler doesn't support it, a warning (at least) should be issued. In that situation, it is unclear whether the compiler can actually generate sensible code. (At the moment, I think the FFI standard says if your platform doesn't support stdcall, code should default to ccall? Obviously that doesn't scale well to java for instance!) (3) Where do we allow the language specifier? In my opinion, definitely in foreign import and export decls. This is at minimum for backwards compatibility, but looking forward to the day when someone writes FFI code for more than one language in the same module (eek!), it will be needed there. For the same reason, I would argue that it belongs in the new kind of decl required for (c). Now how do we tackle the biggest change, issue (c): abstraction of common header/linklib information to a single new sort of decl? Disregarding syntax for the moment, Marcin has suggested a concrete design that conflicts in some ways with backwards compatibility: * the primary specification is of the language not the calling convention * the calling convention is defined as only one attribute of a language * the calling convention is mandatorily removed from its current position in all functions His proposal also adds many of the features that we want: * names of include files * names of link libraries * decl appears once and scopes over all foreign functions in that module * it is not language specific: the attribute-based style allows new languages to have attributes we haven't even thought of yet. and some features that might be nice additions: * the global decl can be overridden for a single function * using an attribute style directly in the existing foreign import/export decls is potentially cleaner, as it can tidy up current blots like 'unsafe', and admits the possibility of needing further ad-hoc specifications in the future. (Didn't someone have an example that involved blocking/non-blocking thread-safety?) Since I believe backward compatibility is very important, would anyone like to either modify Marcin's proposal, or make a new concrete proposal that is perhaps slightly more conservative but still achieves our goals? I suppose backwards compatibility might not be entirely possible. If it isn't, then we have a choice between making the changes as small as possible (to make porting old code easier), or making them as radical as possible (to ensure that the design is really clean and extensible). Regards, Malcolm