On Wed, 31 Dec 2003, Richard Kelsey wrote:

>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?)
>
>                                         -Richard

== the pointer comparison is how you pretty much have to compare
(scheme eq?) any boxed values.  But unboxed values like short
integers, short characters, and floats get compared using ==
the value comparison instead.

I have constants corresponding to the "unboxed value" of #t and #f
on the C side as well, but they are used mainly as data sources.
IE, I don't represent scheme-false and scheme-true by pointing at
them, I represent those values by copying them.  So I do have
freshly-allocated #f's and #t's as unboxed values in the runtime.

unspecific is not a constant at all; I use an error type which
records what form the error arose in and what the values of the
referenced variables were when the form was evaluated.  Thus
instead of #,(UNSPECIFIC) the internal representation (which I
intend to use to support a debugger) is going to be something
like

#,(ERROR: '((car foo) == (<compiled function> ()) 341.20))

indicating that the form (car foo) at line 341 column 20 attempted
to take the car of '().  The error object is returned from the
car operation, and propagated back from there to whatever called
car, etc, until it hits a handler.  These #UNSPECIFIC's are freshly-
allocated boxed values and get compared (by handlers) using a
pointer comparison.

			Bear