Argument lists

[mike%gold-hill-acorn@mit-live-oak.arpa]

    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
        From: mike%gold-hill-acorn@mit-live-oak.arpa
    
        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
    result".

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?


...mike beckerle
Gold Hill Computers.