[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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)
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
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
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
I didn't mention this on the mailing list as a valid use of Type-Of,
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!
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>