Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:51 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:43 UTC)
Re: Couple things... tb@xxxxxx (24 Dec 2003 23:30 UTC)
Re: Couple things... Michael Sperber (27 Dec 2003 18:46 UTC)
Re: Couple things... felix (24 Dec 2003 12:40 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:16 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:51 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:13 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:18 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 21:53 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:42 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:01 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:29 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 04:47 UTC)

Re: Couple things... Tom Lord 05 Jan 2004 22:19 UTC

    > From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

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

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