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. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
