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.