Re: Type-checking of slot values

[kempf%hplabsz@hplabs.HP.COM]

> My preference as stated before is to
> prohibit a rule *requiring* checking of slot values, except that under the 
> extremal safety settings such checking *may* be required.  Note that this
> phrasing grants permission for an implementation to do type-checking at all
> safety levels, if it so chooses.

This sounds consistent with CLtL policy on declarations to me.

> Incidentally, I would propose a benchmark of using defclass for defstruct,
> and see if there is *any* mode where the user suffers no slowdown [:type 
> specifiers aren't the only hinderence to success here!].  Conversely, there 
> should be a test case that asks whether there is *any* mode where all slot
> :type specifiers are always satisfied.

Well, since the change class protocol requires that an implementation be
able to modify the structure of an object while maintaining EQ identity,
there are implementations which could impose an extra level of indirection
into slot lookup. Alternatively, a class could keep track of all its
instances, but garbage collection becomes complicated. I had, at one time,
proposed a set of primitives to freeze the class structure about a certain
class, but there appeared to be little or no interest in this idea, and it
somehow got dropped. This would allow an instance implementation with one level
of indirection, but attempts to change the class would signal an error.

Alternatively, one could modify DEFCONSTANT to allow declaration of
constant structure as well as constant binding. As a general tool, this 
obviously would be very difficult to implement, but for things like
classes and functions, which are named but for which the name/object
binding does not go through the symbol value cell, enforcing it would be
straightforward.

Of course, with real forwarding pointers, the amount of overhead in 
slot lookup becomes much less, since the virtual memory system is
helping you.

		jak