From: xxxxxx@becket.net (Thomas Bushnell, BSG)
   Date: 31 Dec 2003 11:49:59 -0800

   Richard Kelsey <xxxxxx@s48.org> writes:

   > Are there any implementations of Scheme in use where SCHEME_FALSE,
   > SCHEME_TRUE, SCHEME_NULL, or SCHEME_UNSPECIFIC should be freshly
   > allocated?  Or where EQ? and == are not equivalent?  (These are not
   > rhetorical questions; I really would like to know -- is this an
   > existing or only potential problem for portability?)

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

Okay, but that doesn't supply an answer to either question.

Anyway, I just searched through SRFI-50 and found no mention
of C's ==, so I am mystified as to why it is an issue.  The SRFI
does have
  int SCHEME_EQ_P(scheme_value, scheme_value)
for invoking EQ? from C.  I could see adding
  #define SCHEME_IS_FALSE(scheme_value)		\
    (SCHEME_EQ_P(SCHEME_FALSE, scheme_value))
  #define SCHEME_IS_TRUE(scheme_value)		\
    (! SCHEME_EQ_P(SCHEME_FALSE, scheme_value))

The SRFI doesn't say that there are any values that the GC
doesn't care about; in particular it doesn't say that locations
containing SCH_TRUE, SCH_FALSE, SCH_NULL, or SCH_UNSPECIFIC
need not be registered with the GC.  They may be heap objects or
they may not.

This thread started with Tom Lord's statement:

  SCHEME_FALSE, SCHEME_TRUE, SCHEME_NULL, and SCHEME_UNSPECIFIC should
  be functions, not constants:

  Not
        x = SCHEME_FALSE;
  but:
        SCHEME_MAKE_FALSE (&x, instance);

  because, you never know, those constants might be heap allocated.

and then in a second message:

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

I can't imagine why an implementation would allocate any of
these constants on the fly.  Even if you had a system which
had multiple versions of them and the associated complicated
EQ? (which I still don't believe will ever happen), why on
Earth would you allocate the new copies on the fly?

There is a cost to indicating that a functions or macros may
trigger a GC.  Their uses have to be scrutinized to see which
values are live across the use.  It's a total 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.

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