Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!shelby!neon!Gang-of-Four!andy
From: andy@Gang-of-Four.Stanford.EDU (Andy Freeman)
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Message-ID: <1989Nov30.205928.6830@Neon.Stanford.EDU>
Date: 30 Nov 89 20:59:28 GMT
References: <20991@mimsy.umd.edu> <31807@news.Think.COM>
Sender: USENET News System <news@Neon.Stanford.EDU>
Reply-To: andy@Gang-of-Four.Stanford.EDU (Andy Freeman)
Distribution: usa
Organization: Computer Science Department, Stanford University
Lines: 29

In article <31807@news.Think.COM> barmar@think.com writes:
>In the more flexible cases, it is a way for the programmer to declare his
>intentions (he doesn't care about the old structure), and thus permit the
>implementation to try to optimize the operation.

I note that it is okay for an implementation to have "destructive"
operations that actually don't modify their arguments's value.  For
example, an implementation may have a concurrent garbage collector CPU
and have made other design choices such that destructive operations
are actually more expensive than copying the appropriate data.  (Some
implementations of CDR-coding are almost like this.)

Strings (and general vectors as well, although I don't see the point
for them) can be implemented in many ways.  In some cases, destructive
deletions can be made that return a new string object, but a pointer
to the original object (which is not eq to the new one) sees some of
the modifications.

The purpose of "destructive" operations is to allow the programmer to
say "do this fast, reusing whatever of the argument you want, and give
me the result" to the implementation.  If that's not what you want to
do, don't use them.  In particular, if you want a particular type of
reuse, and you want it to be portable, you have to write it yourself.

-andy
--
UUCP:    {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy
ARPA:    andy@neon.stanford.edu
BELLNET: (415) 723-3088