[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no constants please
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
int SCHEME_EQ_P(scheme_value, scheme_value)
for invoking EQ? from C. I could see adding
#define SCHEME_IS_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:
x = SCHEME_FALSE;
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