tb> It is a known strategy for more complex memory systems to have
    tb> a variety of different values for certain constants.

    rk> Okay, but that doesn't supply an answer to either question.
    rk> [....]

    rk> This thread started with Tom Lord's statement:
    rk> [....]
    rk> tl> because, you never know, those constants might be heap allocated.

    rk> and then in a second message:

    rk> tl> Perhaps it would be clearer if I said that those constants
    rk> tl> may be _newly_ heap allocated.

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

tb just gave you one.

    rk> There is a cost to indicating that a functions or macros may
    rk> trigger a GC.

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.

    > Their uses have to be scrutinized to see which
    > values are live across the use.  It's a total pain.

Regarding which both the Pika and JNI/minor-style interfaces provide a
mitigation of that pain.

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

Your critics are proposing only greater _regularity_ in the FFI --
that's sufficient for everything we can imagine in some future
implementation.   You make it sound like we're trying to drive the
decision based on some hypothetical and unlikely future but really,
you can reach the same conclusion we have just by deciding not to
introduce gratuitous special cases in the FFI.

    > If someone produces an undefined-value SRFI that describes
    > undefined-value object containing useful data, such as Bear
    > has in his implementation, then it would make sense to have
    > a way to create such objects from C.  It doesn't make sense
    > to do so now, when there isn't any such SRFI.  Even with
    > such a SRFI there would be utility to having an undefined
    > value that could be used in places where a GC would be
    > undesirable.

Nobody has suggested that you provide a special interface for
bear-style undefineds.  With a parameterless, UNDEFINED-producing
function, bear could define that to good effect as a macro that
implicitly passes __FILE__ and __LINE__ and the like.

-t