Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!bloom-beacon!think!ames!ucbcad!ucbvax!decvax!decwrl!labrea!Gang-of-Four!weening From: weening@Gang-of-Four.Stanford.EDU (Joe Weening) Newsgroups: comp.lang.lisp Subject: Re: cdr encoding (was Re: Importance of REPLACA, REPLACD) Message-ID: <8052@labrea.STANFORD.EDU> Date: Sat, 18-Jul-87 17:13:19 EDT Article-I.D.: labrea.8052 Posted: Sat Jul 18 17:13:19 1987 Date-Received: Sun, 19-Jul-87 06:43:05 EDT References: <22@citcom.UUCP> <6900008@iaoobelix.UUCP> <19747@ucbvax.BERKELEY.EDU> <17815@cca.CCA.COM> <19760@ucbvax.BERKELEY.EDU> Sender: news@labrea.STANFORD.EDU Organization: Stanford University Computer Science Department Lines: 39 Actually, in [1, p. 38] Harrison says "While the operation RPLACA is no different to perform using our representation than when using a conventional one, the increased level of sublist sharing causes a concomitant increase in the likelihood of RPLACAing a shared cell, and makes it practically impossible to give a precise semantic definition of the construct. ... Nevertheless, because it is so straightforward to perform the operation itself using our representation, further investigation is needed to decide if RPLACA can be incorporated in an orderly way." I tend to disagree with the first part of this, at least in the case of a single-process program (or a list structure known to be accessed by only a single process). In this case, I think techniques such as developed in [2] can be used to adequately define the semantics, and there may be cases where RPLACA is of some use. Of course, if you want RPLACA to have the exact same semantics as with a conventional pointer-based list representation, there will be problems. But I suspect that this is rarely needed. RPLACD is another story. Here again I think it could be implemented with a well-defined semantics, but the resulting operation would be much less useful than the conventional RPLACD, as Harrison points out, and to do the standard RPLACD is quite difficult with this representation. Since this representation was designed for a parallel Lisp, and the parallel semantics of RPLACA and RPLACD will make them much less useful than the serial forms, I can see why he chose to remove them from the language. Joe Weening [1] W. L. Harrison, "Compiling Lisp for Evaluation of a Tightly Coupled Multiprocessor", Center for Supercomputing Research and Development Report No. 565, Urbana, Ill., March 1986. [2] I. A. Mason, "The Semantics of Destructive Lisp", Center for the Study of Language and Information Lecture Notes No. 5, Stanford, Ca., 1986.