On Wed, 31 Dec 2003, Richard Kelsey wrote:

>Are you saying that your definition of EQ? looks something
>like this (translated to whatever language you are using)?
>
>  (define (eq? x y)
>    (if (boxed? x)
>        (and (boxed? y)
>             (pointer== x y))
>        (and (unboxed? y)
>             (value== x y))))
>

Close to that.  There are a few corner cases because you
can have the situation where one value is boxed and the
other is not.

>Boxed and unboxed values must be the same size, presumably,
>so why are two different operators needed?

Actually they don't.  Unboxed values are 64 bits in my call frames
and boxed values are 32 bits.  Wherever I can prove that things
are going to be boxed values, I can use a faster equality predicate
to compare the C union between boxed and unboxed values.

Perhaps I'm using 'unboxed' in a different way.  When I say 'unboxed'
I mean a literal value rather than a pointer to a value.  I use
unboxed values when possible in my call frames in order to reduce
pointer-following overhead. Strings, Cons cells, vectors, etc,
always have to be boxed since they refer to mutable locations
rather than pure values.  Other things may be represented by
immediate values, or boxed values referring to possibly-identical
values that are in different locations.

Anyway, I know that a specific bit pattern is always going to mean
#t, in every run.  If I were using  'boxed' booleans, I could compare
equality using == (because it would be pointers to the same instance
of a location containing the value) but I wouldn't know whether the
things being compared were actually #f and couldn't, without doing
some pointer-following, make other optimizations based on that
knowledge, like recognizing and optimizing forms such as
(if #f <nevermind> <just do this>).

>   car, etc, until it hits a handler.  These #UNSPECIFIC's are freshly-
>   allocated boxed values and get compared (by handlers) using a
>   pointer comparison.
>
>Sure, but a portable FFI cannot assume that the implementation
>supports your type of unspecific value.  Having the FFI use
>a single 'unspecific' value works in your implementaion (you
>just create a single unspecific value for use in C code).  It
>isn't as useful as it might be in your implementation but it
>is portable.

Sure.  For a portable FFI, I'd allocate an object that was just

#,(NONSPECIFIC: "returned from code accessed through FFI")

and the FFI could treat that as "the" constant value.

			Bear