Michael Sperber wrote:

>>>>> "Tom" == Tom Lord <xxxxxx@emf.net> writes:

Tom> One approach to this, that taken by the draft, is to make an FFI that
Tom> models a substantial part of the semantics of the high-level language
Tom> -- then let the FFI-using programmer fill in the gap between that and
Tom> our target libraries.

Tom> Another approach, that proposed by Felix (if I'm reading right), is to
Tom> make an FFI that captures the semantics of the libraries in a
Tom> first-class way -- then let the FFI-_implementing_ programmer fill in
Tom> the gap between that and his high-level language implementation.

> That's also how I'd state it.  To my mind, this means the two
> approaches are complementary rather than exclusive.  But Felix seems
> to disagree.

The two approaches are not complementary at all. The approach taken
by this draft is to expose very many implementation
dependent details. And the authors basically justify this
with a) highly subjective (and IMHO incorrect) performance considerations
and b) by simply ignoring anything but simple-minded implementation
strategies. The alternative (with is *not* complementary to (a)), would
be to hide the details (either using extra indirections or mapping
argument/return values to C types, transparently, under full control
of the implementor, and (this is important) making *no* assumptions
about read/write-barriers, GC model, string representation, threading
model, etc.
My point is that all these issues *can* be addressed, not by specifying
each and every little detail, but by simple adding a layer of abstraction.

cheers,
felix