Re: Exact type

[Patrick H Dussud <DUSSUD%Jenner%csl.ti.com@RELAY.CS.NET>]

     >				The user shouldn't expect
     > that an argument will be exactly of this built-in type.  On some
     > machines, you cannot expect an cons cell argument to be always of the
     > exact type CONS.
     >      
     
     Now I think I understand. We're coming from two different directions,
     as far as typing is concerned. Your direction seems to be the structural
     equivalence one, that is, two data items are of the same exact type
     if they have the same structure. My direction is operator equivalence,
     two items have the same exact type if you can apply the same set of operators
     to them.  

For me (this is, if I understand you proposal on optimization correctly)
two types are the same if their applicable methods are the same for all
of their operators.  It is a necessary condition for method
discrimination optimization.  If you have a built-in type, say CONS and
you write: 

(defun foo (x a)
  (declare (exact-type cons X))
  (rplacd X a)
  a)

The compiler would assume that it knows what methods are applicable
to this call to REPLACD and will do some useful optimizations.
However, it may happen that the system supplies foo with a CONS cell of
type STACK-CONS, that you (portable user) didn't expect.  The function
foo would not work under this condition because RPLACD has a method
defined on STACK-CONS, shadowing the one on CONS.
     
     I'll rewrite the Cleanup Committee submission to reflect the restriction
     you requested (unless I hear other objections), but I'd suggest we change
     the name back to EXACT-CLASS, since the built-in types are no longer
     covered.

OK.