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.
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> >>>>> "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.
I think it's not so much a disagreement about possibility as a
disagreement about practicality.
If the reification of the HLL into C is too hard -- perhaps the
reification of C into the HLL is easier.
(Personally, I think that the reification of the HLL into C is _not_
too hard, but also that the draft isn't it.)
Even beyond the "either or" -- layering the C-into-HLL on top of the
HLL-into-C may be (likely will be) distinctly less efficient, in a
portable FFI, than just doing C-into-HLL directly. So, yes,
complementary (which is all you said), but (a) C-into-HLL may be more
than enough functionality and (b) HLL-into-C may be more than needed,
and less than necessary.
-t