[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Tue, 1 Jul 86 13:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 1 Jul 86 10:13 EST
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function.....
Doesn't this conflict with the possibility of (type-of <function>) telling
you whether it's an interpreted or compiled function, and whether it's
a closure or not, and (in some systems) whether it's generic or not?
Or, as CLtL says, "(type-of object) returns an implementation-dependent
This depends on what you think type-of is supposed to do.
Maybe we need a new function name, but as far as I'm concerned,
closures, (compiled or not) and functions, can all have the same type,
that is (function (...) ...), as do all applicable objects.
However, their representations have different types. The question
really boils down to whether type-of is supposed to tell you something
about the CL type lattice, or the representation of the object.
My interpretation of CLtL was that type-of returns an implementation
dependent result, in that the "precision" of the type might vary
from one interpretation to another. The "weakest" type-of would return
types of defstructs, and type t for everything else. The strongest
(and certainly unachievable) type-of would return complete function
signatures for all applicable objects, etc. In every case, what is
returned is a CL type, not the rep type.
Generics are a much harder problem, since their type signatures can
be really elaborate. I assume you mean by generics the kind of
overloaded operators you can get in Commonloops and New Flavors?
Are the implications of these for the type system understood at all?
Will CL have anything left of a type system after this kind of
overloading becomes the norm, or can we somehow salvage it?
Gold Hill Computers.