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