Manuel wrote:

[...] * I want to get v1.0 of the spec fixed. We are really only in bug fix mode for quite a while and only the finalizer problems held us back from finishing the spec.

That's OK and I understand your motivation. Let's finish v1.0 first.

* I am sure there are plenty more useful FFI-related libraries. However, the initial plan was to define basic functionality on top of which more elaborate schemes can be implemented. We need to draw the line somewhere. [...]

But I strongly disagree here: The initial plan was to make a very small, but sufficient addition to the language (=> foreign import/export), which can be implemented easily on existing systems. In this respect, we have reached our goal quite elegantly IMHO. The related libraries are a totally different beast: Minimality is *not* a design goal here. Otherwise we might be happy with e.g. Foreign.Marshal.Alloc.mallocBytes Foreign.Marshal.Alloc.allocaBytes Foreign.Marshal.Alloc.reallocBytes Foreign.Marshal.Alloc.free Foreign.Marshal.Util.copyBytes Foreign.Marshal.Util.moveBytes alone. Or another example: Why should we include such trivialities like Foreign.Marshal.Error.void or Foreign.Marshal.Util.toBool in the FFI spec? Minimality? Possibility of a lightning-fast special implementation? Definitely not. The basic task of a library (or a collection of related libraries) is to establish a common "language" and make common notions (like scoped or pooled allocations) explicit. Looking at the OO world, that's the reason for all this pattern hype. In a nutshell: Let's include as many useful "patterns" in the next FFI spec versions as possible! Otherwise we might talk the same language without recognizing it... Cheers, S.