Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Message-ID: <1514@skye.ed.ac.uk>
Date: 8 Jan 90 20:35:05 GMT
References: <8911291447.aa13784@PARIS.ICS.UCI.EDU>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 74

In article <8911291447.aa13784@PARIS.ICS.UCI.EDU> Schwamb@ics.UCI.EDU ("Karl B. Schwamb") writes:
>
>michaelg@Neon.Stanford.EDU (Michael Greenwald) writes:
>>CL-delete doesn't side-effect the environment, while your macroized
>>delete does.
>
>I'm confused here.  The semantics of delete side-effects the environment
>by changing the value of the sequence.  The macro form may side-effect 
>a variable through a setf but I don't see any real difference between
>that and altering its structure.

Well, let's start by just saying there's a difference: in one case,
a variable is given a new value; in the other the variable keeps the
same value, but the value is modified.  "Side-effects the environment"
is just another way to say "assigns to a variable".  "Environment" is
being used in a special sense here.

This difference can matter; but changing the structure is usually
considered to be more dangerous than assigning to a variable, rather
than the other way around, because other variables might point to
the same structure.

>If you advocate a functional approach then it would seem that "remove"
>should be used rather than "delete". 

Just so.

>Since delete is designed to be destructive, its only advantage seems
>to be speed since functional style would advocate "equal" checks in
>subsequent code rather than "eq".

Destructive operations aren't just a matter of efficiency.  There's
also a conceptual difference.  For example, one way to model
real-world objects that change over time is to use Lisp objects
that change (via destructive operations) over time.

>barmar@think.com writes:
>
>>For instance, what happens when sequence isn't a place that can be SETFed?
>
>I would think this could be checked during code generation.

True, but what if you still want to perform a delete in one of the
cases where the SETF was impossible?  The DELETE function would still
be useful in this case.  So I wouldn't want to replace that function
by the macro.

>>Or what if you didn't really need to store the result back into the
>>variable the list came from, e.g.
>
>I think a better implementation would check if a list were being
>used and the first element had been deleted.  Only in that special
>case would a "setf" occur.

But what if you don't want to store the result back in the place
the list came from?  What if you want to put it somewhere else,
for example, as in

   (setq b (delete 'this a))

>This seems a small price to pay to get a consistent delete function.

Consistency depends on how you look at it.  In Lisp, one often thinks
of data objects as independent of variables.  You get your consistency
only in cases where a list and a setf-able place are considered
together.  It still isn't a consistent operation on an object standing
alone.  For that, you'd need to use a headed list or something of that
sort.

However, there's nothing wrong with defining a macro to delete-in-a-
place.  There are already similar operations in Common Lisp, such as
PUSH and POP.

-- Jeff