[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Couple things...
> 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.