Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!samsung!think!think.com!barmar
From: barmar@think.com
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Message-ID: <31807@news.Think.COM>
Date: 29 Nov 89 20:46:41 GMT
References: <20991@mimsy.umd.edu>
Sender: news@Think.COM
Distribution: usa
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 33

In article <20991@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes:
>I take it from the Common LISP Reference that functions marked "(destructive)"
>are destructive in the sense that they *may be* destructive in some way.
>Is it thus true that I cannot count on destructive behavior when I want it?

ANSI CL is going to be a bit more clear about which destructive operations
can be "counted on" and which can't.  For instance, NCONC will be specified
pretty fully (it RPLACD's the last cons in each non-null argument except
the last), as will NSUBSTITUTE (it RPLACA's or SETF-AREF's as appropriate).
The specifications of some others, such as DELETE and NREVERSE, will say
"may reuse any part of the sequence."  We addressed these on a case-by-case
basis, trying to balance implementation flexibility against user needs and
expectations.  NCONC is specified explicitly because it has a long history
and programmers have come to expect and rely upon its obvious
implementation; NSUBSTITUTE is specified explicitly because we couldn't
imagine an alternate implementation that would violate the requirement.
DELETE is flexible because its definition prevents it from always reusing
the input argument (e.g. if it has to delete all the elements of a list);
NREVERSE is flexible because there are a number of known implementations of
lists that have different optimal algorithms for reversing in place
(traditional lists are typically reversed by reordering the CDR chain,
cdr-coded lists are best reversed by replacing the CARs).

>So destructiveness is an option for the convenience of LISP
>implementation creators, not users?

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.
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar