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