This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
Michael Sperber wrote:
"Tom" == Tom Lord <lord@xxxxxxx> 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