Re: Data-types for "descending" during copying

[Jon L White <JONL at MIT-MC>]

   Just got your note about the meaning of COPYTREE, and the 
question about "PAIR".  First let me explain that I wanted to
CC this reply to the LISP-DISCUSSION people, since the extended 
"copy" question reveals quite a bit about the semantics of new
data types in LISP, and it might be a good thing to think of
the inter-dialectic differences.  (since both LISP-FORUM and
LISP-DISCUSSION are mailing lists here at MIT-MC, I hope no one 
gets two copies of this note;  if you do, please send me notice 
of this fact, and maybe someone here can do something about it)
    Re the name PAIR, it is fully equivalent to a "CONS" -- the 
name PAIR has been used by the StandardLISP people for a long time,
and the NIL people seem to favor it too  (since NIL and MUDDLE
distinguish between the nullist and other "pairs", the "LIST" data 
type must be a union of "PAIR" and "NULL").  So if COPYTREE is to 
be the name for the pair-only descending copier, then that is fine.
   Still, we must address the next level of copying, namely something
which descends the normal "hunk"-type data -- for StandardLISP and NIL
this would include VECTOR's, Maclisp would include HUNK's, and for
just about all lisps it would include S-expression (or ART-Q) ARRAYs.
(Please, please, don't anyone else *ever* implement HUNKs, let MacLISP
rest in peace, if you must do it, then give them the generality of
VECTORs).  Although one could argue that SYMBOLs have "components",
and would thus be descendible, I believe there is some reasonable
stopping point for this level of "copyist",  e.g., SYMBOLs, numbers
of all kinds, non-S-expression arrays, etc.
   The other important extension for copyings is to "instances" of
classes-of-objects (yes, there seems to be a lot of fast-changing
terminology these days, what with flavours, classes, smalltalk, etc).
I believe the generic notion for this data type is caught by the NIL
"EXTEND", which is more-or-less the admixture of ECL's TYPES with the
capabilities for any of the emerging message-passing protocol's.
EXTENDs have been "piggy-backed" onto MacLISP in order to get a modest
class system, and a bunch of new data types; and here we chose to have
SUBST send a "SUBST" message.  If a new function is admitted, with a
slightly broader authorization for copying than COPYTREE, then no new
messages need be introduced (i.e., we don't need a :COPY-SELF message), 
since the implementation of such a new function could utilise the SUBST 
message.  Isn't it true that SUBST is more primitive, in that "copy-self"
can be reduced to the "(subst () () x)" hac, but SUBST cannot be reduced 
to any mere straightforward usage of :COPY-SELF ?