TYPE-OF

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Fri, 21 Nov 1986  09:36 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Date: Wed, 19 Nov 86 23:41:56+0900
	From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
	To:   common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET
	Re:   TYPE-OF

	D-Eval concept needs TYPE-OF.  kinds of type inferencing system
	will also need TYPE-OF to determine the type.
	Here is a conversation with D-Eval:

	D-Eval>(+ 1 2)
	3
	; FIXNUM

    Well, if all D-Eval uses Type-Of for is to print out the type, then it
    doesn't really matter what it returns.  I had in mind a fragment of
    code that needed to use Type-Of.  I don't know exactly what you mean
    by a "type inferencer", but for the kinds of type inferences that I
    could conceive of a Lisp compiler wanting to do, you definitely want
    the *most specific* type, and certainly don't want to return random
    things such as FIXNUM which represent implementation details rather
    than language semantics.
Eh?  You're contradicting yourself.

Compilers deal directly with implementation, and that's
why you want something more specific, such as FIXNUM,
rather than something at the level of language semantics,
such as INTEGER.  I think you're trying to argue that you
want something more specific still, but that's not TYPE-OF's
job.

    Now, if A is known (due to declaration) to be 
    (array (unsigned-byte 8)), then I could combine the fact that 7 is
    (integer 7 7) with that information to determine that the result of the
    addition is (integer 262 7), which is probably a useful thing to know.
    If all that I know is that 7 is FIXNUM, then all bets are off.
If all you have is TYPE-OF and SUBTYPEP, yes, that is true.
If you don't want to throw away information, keep the
original object.

In a recent message, I oversimplified TYPEP, because I'm
trying to stay out of certain issues better handled in
a paper, where hopefully I can be more careful and
verbose.  So I lied a little.  Let's consider that
lie for a moment.  (My apologies for presenting all of
this in such a fragmentary way).

In that other message, I defined TYPEP as

(defun typep (object type)
  (subtypep (type-of object) type))

This mostly works.  However, this depends on TYPE-OF
returning the most-specific type, so for any appropriate
type for an object, TYPE-OF will return something at
least as specific, and which SUBTYPEP can decide on.
Let me assert at this point, without proof, that there
is no such single type.

The problem is that TYPE-OF is inherently an information-losing
operation.  The pair TYPE-OF/SUBTYPEP is actually a special
case of a more general matching process that I really don't want
to go into right now.  The key point, however, is that TYPEP
actually does some things that SUBTYPEP can't, because it actually
has the object.  The same is true of your "type merger" for addition,
which should look at the actual object when it has one, and not
call TYPE-OF.

    I didn't mention this on the mailing list as a valid use of Type-Of,
    since:
      1] The compiler *is* the implementation, so it doesn't matter if it
	 is implementiaton dependent.
      2] The version of Type-Of that I am using in the compiler is
	 optimized to return what the compiler considers most interesting,
	 rather than what the user might consider most informative.  For
	 example, given a symbol, it returns (member <symbol>).

This is an interesting approach.  It reduces TYPE-OF/SUBTYPEP to TYPEP!