Re: gvector question

On Sat, 13 Aug 2005, bryan o'connor wrote:

>> If this comes up in the ANSI tests, do you remember
>> which test(s) provoked it ?
>
> it didn't.  i needed to use it to test if a structure had
> slots before performing *print-level* truncation.
>
> first of all, i was misusing sd-slots.  i was passing it
> a structure instance instead of the result of struct-def.
>
> the cdr of sd-slots is where the slots actually begin.
> the *print-length* logic in write-a-structure was broken
> because it thought that the car of sd-slots was a slot
> (or at least it was counting it as a slot when figuring
> out how much to print).  did that change at some point in
> the past?

I don't remember for certain, but my general impression is
that much of the implementation of DEFSTRUCT is about 20
years old, and very little has changed in that code during
that period.  (The motivating factor in the original design
may have been to pack as much information into as few bytes as
possible; it's not clear why this was ever so important in
DEFSTRUCT's case.)

One change that happened a few years ago is that there's
a little more CLOS/MOP integration than there once was; it
may be easier for things like the printer to use CLASS-SLOTS
and other relatively high-level things and to steer clear of
SD-SLOTS and friends.  (I don't promise that the CLOS/MOP
integration is complete enough to make that practical, but I'd
be surprised if it wasn't at least very close to being complete
enough.)

> changing the sd-* functions to use svref has
> the side-effect of throwing a type-error if one tries to
> pass it a structure.

That's good.  CL:SVREF is perfectly safe under normal optimize
settings; CCL::%SVREF is potentially dangerous.  Even if existing
uses of SD-SLOTS and similar accessors are all safe and correct,
it doesn't hurt to be a little paranoid about it.