Email list hosting service & mailing list manager

Re: no constants please Richard Kelsey (04 Jan 2004 18:11 UTC)
Re: no constants please felix (04 Jan 2004 19:25 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:08 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:13 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:43 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:59 UTC)
Re: no constants please Tom Lord (05 Jan 2004 00:50 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:19 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:42 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:26 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:49 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:24 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:00 UTC)
Re: no constants please Michael Sperber (06 Jan 2004 07:42 UTC)
I don't believe in "(may GC)" Tom Lord (05 Jan 2004 00:55 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:07 UTC)
Re: I don't believe in "(may GC)" Shiro Kawai (05 Jan 2004 12:45 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 18:16 UTC)
Re: I don't believe in "(may GC)" Tom Lord (05 Jan 2004 16:35 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:54 UTC)
Re: I don't believe in "(may GC)" tb@xxxxxx (06 Jan 2004 01:39 UTC)
Re: I don't believe in "(may GC)" Michael Sperber (06 Jan 2004 07:39 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:05 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:12 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:17 UTC)
Re: no constants please Tom Lord (05 Jan 2004 17:40 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 19:03 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 01:37 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 02:15 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:29 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:10 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:06 UTC)

Re: no constants please Tom Lord 04 Jan 2004 22:09 UTC


    > From: Richard Kelsey <xxxxxx@s48.org>

    > The JNI style of FFI, where the C code has indirect references
    > and never the Scheme values themselves, has lots of advantages.
    > But it does add overhead.  I would prefer an FFI that allowed a
    > choice of direct or indirect values on a per-function basis.
    > Which is preferable depends a lot on what the C code is doing.
    > Such an FFI would be even larger than the current one, which is
    > already big.

Pika-style conventions come very close to letting the compiler decide
when direct vs. indirect references are needed.   So close that I
think you can just leave it at that and not suffer.

    > The interaction between Scheme threads and C code is complex.  It
    > deserves a separate SRFI because of the complexity, because of the
    > dependencies on the details of both the thread and C FFI systems,
    > and because not every FFI user is going to care about it.

If this issue were _only_ about threads, that might be a reasonable
argument.  (It also might not: one could argue that you shouldn't
finalize a SRFI which is demonstrably unsuitable for threaded
situations.)

But the problems with the current FFI include issues with
single-threaded, no-async-issue Scheme implementations including:

~ don't handle read/write barriers properly
~ don't handle transient root set members properly

By stunning coincidence (or deep physical truth, take your pick), it
turns out solving those issues _also_ make the FFI much more suitable
for systems with threads (including truly concurrent threads) and
async-execution.

There's another way entirely to look at the calling convention issues:

The draft FFI makes strong presumptions about the representations of
Scheme values and the invarients that must be maintained wrt to the
Scheme heap.  It makes these presumptions by leaving it up to the
compiler of FFI-using functions to manipulate scheme values directly,
constrained only by the semantics of C.

Pika-style conventions do not make those presumptions:  there is a
comprehensive abstraction barrier there between the Scheme value
representations, the heap invariants, and the C code.

The latter is far less restrictive on Scheme implementations.

-t