[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Data-types for "descending" during copying
- To: DLW at MIT-MC
- Subject: Re: Data-types for "descending" during copying
- From: Jon L White <JONL at MIT-MC>
- Date: Sat ,14 Mar 81 08:11:00 EDT
- Cc: LISP-FORUM at MIT-MC, LISP-DISCUSSION 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 ?