This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
From: tb@xxxxxxxxxx (Thomas Bushnell, BSG) Date: 31 Dec 2003 11:49:59 -0800 Richard Kelsey <kelsey@xxxxxxx> 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