Date: Wed, 31 Dec 2003 13:59:09 -0800 (PST)
   From: Tom Lord <xxxxxx@emf.net>

       rk> I can't imagine why an implementation would allocate any of
       rk> these constants on the fly.

   tb just gave you one.

No, (a) he gave a reason why you might have multiple C values
representing Scheme's #F.  He didn't give a reason why
you would allocate those values on the fly (as opposed to
creating them when the corresponding heap is created).
And (b), my point is not that there are no advantages for
doing so, but that any benefit from it would be outweighed
by associated costs.

   So, basically, you don't care about threads or async execution?  It's
   only if you don't care about those things that you need to indicate
   which functions may trigger GC.  Otherwise, GC may occur anytime that
   it isn't specifically excluded.

Absolutely correct.  Within the context of this SRFI I don't
care about asynchronous execution (I do care about threads,
but as long as C code is not interrupted asychronously they
don't matter).  The GC protection mechanism described in the
SRFI is inadequate if GCs can occur asynchronously.  Even if
variables 'a' and 'b' are protected, there is no guarentee
that
   a = b;
will not temporarily store the value of 'b' in some unprotected
location such as a register.

       > I can't see declaring that SCHEME_FALSE, SCHEME_TRUE,
       > SCHEME_NULL or SCHEME_UNDEFINED might trigger a GC just because
       > there might someday exist such an implementation.

   You haven't given any _positive_ reasons for making exceptions of
   those values.

We aren't making exceptions of those values.  We carefully
tried to minimize the number of GC-triggering operations.
Why would it be more regular to label them as possibly
causing a GC?  It would be more regular to label everything
as possibly causing a GC, but that would make writing C code
that used the FFI too painful.
                                       -Richard