Email list hosting service & mailing list manager

Re: no constants please Richard Kelsey 31 Dec 2003 18:24 UTC

   Date: Wed, 31 Dec 2003 09:09:09 -0800 (PST)
   From: bear <>

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

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

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

   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.

I don't understand what a freshly-allocated unboxed value
is.  'Unboxed' normally means 'not in a heap (or stack or
whatever)'.  How do you allocate something that isn't in a

   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

   #,(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.

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.