Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!im4u!rutgers!sri-spam!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uicsrd!harrison
From: harrison@uicsrd.csrd.uiuc.edu
Newsgroups: comp.lang.lisp
Subject: Re: cdr encoding (was Re: Importanc
Message-ID: <47400012@uicsrd>
Date: Sun, 19-Jul-87 23:47:00 EDT
Article-I.D.: uicsrd.47400012
Posted: Sun Jul 19 23:47:00 1987
Date-Received: Thu, 23-Jul-87 03:23:19 EDT
References: <19760@ucbvax.BERKELEY.EDU>
Lines: 37
Nf-ID: #R:ucbvax.BERKELEY.EDU:19760:uicsrd:47400012:000:1826
Nf-From: uicsrd.csrd.uiuc.edu!harrison    Jul 19 22:47:00 1987


	Jim has hit the nail on the head.  The storage scheme does not
make RPLACA difficult to perform, but the increase in sublist sharing makes
it difficult to give it a precise meaning.  Whereas with conventional list
representations, the sharing that results from an APPEND operation is
apparent, using the representation I've proposed the sharing that results
is in part a function of previous APPEND operations.  For instance,
in the code fragment

        ...
        (IF CONDITION1 (SET! A (APPEND B C)))
        (IF CONDITION2 (SET! D (APPEND B E)))
        ...

D and B may wind up sharing all of the cells in B's top level, if
CONDITION1 is false; that is, if (APPEND B C) does not occur.  If
(APPEND B C) occurs, then A and B will wind up sharing all of the cells
in B's top level.  It seemed unreasonable to expect a user to be able
to sort out who was sharing what with whom, and so we ended by declaring the
representation unfit for use with RPLACA as well as RPLACD.

Another way of looking at it, as Jim pointed out, is that if RPLACA and RPLACD
are making the life of the parallelizer (human or automatic) miserable, then
why not lop them off, and take full advantage of the immutability of cons cells
by increasing storage efficiency, providing for fast (parallel) access to top
level cells, allowing recurrences over lists to be solved in parallel,
etc?  (In the lisp system we're currently developing, there are lots of
other mutable objects: structures, variables, hashtables, etc., so the loss
of expressive power is relatively minor.)

--
Luddy Harrison,  Center for Supercomputing R&D, U of IL at Champaign-Urbana

UUCP:	 {ihnp4,seismo,pur-ee,convex}!uiucdcs!uicsrd!harrison
ARPANET: harrison%uicsrd@a.cs.uiuc.edu
CSNET:	 harrison%uicsrd@uiuc.csnet
BITNET:	 harrison@uicsrd.csrd.uiuc.edu or harrison@uicsrd