Re: Type-checking of slot values

[kempf%hplabsz@hplabs.HP.COM]

>     > I don't think that the type checking has anything to do with good
>     > performance. The important thing for good performance is that  an
>     > implementation an optimize slot access based on :type information. I
>     > don't want to take that away from CLOS, or CLtL.

>     Sorry, but I think you're wrong. On stock hardware, FIXNUM + is one
>     instruction, and a compiler which can deduce when to use it will always
>     win over one that can't.

> What does this have to do with a requirement that a particular construct
> shall signal an error in a particular circumstance?

Nothing, which is probably as good a reason as any to terminate the discussion.

> I think you two are using the phrase "type checking" to mean two different
> things.

Right: 1) to check for errors 2) to help optimize performance. The
current Common Lisp declaration framework can do 2), though the compiler
may have to be smarter in some cases (which could be simpilified by
adding some declarations). Since the Common Lisp specification makes
declarations optional, however, the results of declaring things may be 
nonportable. I presume by "should CL become statically typed" is meant 1), 
to which my feeling is no, but this is not the right place to discuss it.

> Note how I resist the urge to point out that a certain vendor's
> processor, which said vendor claims is the only stock hardware anyone
> would ever want to use, and has in fact succeeded in convincing several
> other corporations of the merits of that idea, has a Common Lisp +
> instruction.

I'll refrain from asking specifics [  :-)  ], but I don't oppose the idea
of having instructions for high use operations like Common Lisp +. 
I think the language design should make it possible to implement
with relative efficiency (at perhaps larger compilation cost) even on
architectures which are less enlightened, however.

		jak