[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns)
Date: 18 Nov 86 21:04:00 GMT
Here is an example of completely-portable code which depends on
TYPE-OF returning the MOST specific type.
(defun store-in-array-if-fits (object array &rest indicies)
(let ((object-type (type-of object))
(array-type (array-element-type array)))
(if (subtypep object-type array-type)
;; If the object fits, store it
(setf (apply #'aref array indicies) object)
;; Doesn't fit, so store 0 instead.
(setf (apply #'aref array indicies) 0))))
Sorry, I can't buy this motivation. All this example illustrates is that
there is a good reason for having the TYPEP function around.
As it happens, in PCLS, TYPE-OF does go through a considerable amount of
work to find the most specific type that it can. So, (TYPE-OF 0) returns
BIT, which is correct but largely useless. My "gut feeling" is that what
the user probably wants is either FIXNUM or INTEGER -- something which
indicates how the object is represented internally, or (in other words)
one of the set of types which CLtL says are disjoint.
I'll have to agree that TYPE-OF as defined now is pretty bogus. The only
place I've ever had reason to use TYPE-OF in real code was to get a type
to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two
objects were of the same type; for example, both lists or whatever. But
this is full of holes, too. For example,
(coerce '#(a b c) (type-of (list)))
may fail, depending on whether your favorite implementation thinks NIL is
of type NULL, LIST, or SYMBOL. I ended up writing a specialized function
to do what I wanted, without relying on TYPE-OF.
In short, I am not convinced that TYPE-OF would be particularly useful even
if its definition were firmed up more. If nobody has any good use for this
function, arguing over how it should behave is rather pointless.
- From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>