[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.