type-of

[sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)]

    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.

-Sandra
-------