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