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

    > Ray> It's not immediately obvious to me how to implement some of the
    > Ray> functionality that's not allowed to GC without allocating call
    > Ray> frames - particularly since strings are represented internally
    > Ray> as a tree structure.  I'll look more closely at it tomorrow and
    > Ray> cite specific cases.

    > As to the strings & characters issue---we all agree that it
    > needs to be addressed.  But apart from that?

I think "may GC" applies to all entry points.

Even something banal like "extract_double" may wind up having to
reduce a number by running Scheme code (as in a bignum rational with
bignums implemented in Scheme (or just on the Scheme heap) or a
continued fraction numeric extension written in Scheme).

Other examples of the problem are process migration and persistent
stores which are, I think, something that people are likely to take a
stab at more often these days.  If anything, very simple
implementations are one of the more likely places for those kinds of
feature to show up.

(Why the "constants" should be an exception to "may GC" is something I
can't imagine.)

I think we've cooked down the implications of some FFI design space
parameters to this:

   Parameter			Restricting		Resulting
				Choice			Restriction
   ----------------------------------------------------------------

   A. GC only at certain	Yes		Aynchronous threads may
      C sequence points?			not cause GC;  signal
                                        	handlers may not cause
                                                GC

   B. Scheme values		Yes		Requires A
      repesented as
      C rvalues?

   C. Barrierless reads		Yes		Certain incremental GC
      and writes to Scheme			techniques prohibited;
      locations?				Requires A and B

Note that (not A) implies (not (or B C)).   Coherent choices here are:

	1. no to all three
        2. A (and B?)		(A+B has no disadvantage compared to A?)
        3. A, B, and C

each progressively more restrictive than the last.

(The chart doesn't talk about "human factors" restrictions like
tempting users to mistakenly write `cons (a, cons (b, nil))'.)

Supposing that your choice is (A+B) or (A+B+C), then there's a new
parameter which is what you're asking Ray about:

   D. Some FFI functions may	Yes		Scheme types not extensible
      not cause GC                              in Scheme;
                                                Some scheme types or procedures
                                                not implementable in terms
                                                of others;
                                                (Implies A, of course)

which strikes me as eerily Java-esque.  Incrementally better in that
there is still a _little_ room to "subclass" (for example) the number
type or cons-pair type -- but only by a tiny increment since there
would still be a huge restriction on representations of (for example)
small, exact, integers or pairs.  (So much for that big Oaklisp
revival?)

In all cases, the "resulting restriction" becomes implicit in
FFI-using code.  An implementation that promises users support for an
A+B+C+D FFI in one release can not also promise to add asynchronous
execution in an upward compatible way, can not plan to use certain
incremental GC techniques while remaining upward compatible with code
that uses the FFI, and can not promise to compatibly add extensibility
of the basic Scheme types.

Does it make sense to request implementation of those restriction
in other people's implementations?

-t