Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!jarthur!uci-ics!gateway
From: Schwamb@ics.UCI.EDU ("Karl B. Schwamb")
Newsgroups: comp.lang.lisp
Subject: Re: Are "destructive" functions really destructive?
Message-ID: <8911291447.aa13784@PARIS.ICS.UCI.EDU>
Date: 29 Nov 89 22:50:02 GMT
Sender: schwamb@ci2.ICS.UCI.EDU
Lines: 55
To: comp.lang.lisp@ci2.ICS.UCI.EDU


michaelg@Neon.Stanford.EDU (Michael Greenwald) writes:

>By the way, your implementation doesn't work when sequence is the
>result of function application.  It is illegal to "apply" (if such
>terminology is appropriate for a macro) SETF to something that isn't a
>"place".  Or is this one of the things you were referring to when you
>said "this doesn't do all the proper checking"?

Good point.  I guess special forms wouldn't help either, sigh.

>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.

>Yes, CL-delete does side-effect sequence (and if sequence is shared,
>and isn't just an intermediate result, then the side-effect is visible
>in the "environment"), but if delete is always used "functionally"
>(for value) you can argue convincingly that cl-delete is cleaner than
>your delete (if you subscribe to the notion, as many do, that
>side-effects aren't particularly clean, and therefore should be
>minimized).

If you advocate a functional approach then it would seem that "remove"
should be used rather than "delete".  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".  When functional style has to be abandoned in large systems
requiring efficiency or small systems requiring space, then it becomes
a question of how you'd like your destructive operations to work.
I agree that side-effects should be minimized, but I also think
they're rarely unavoidable in large systems.


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.

>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.  This seems a small price to pay to
get a consistent delete function.

Karl B. Schwamb                                  schwamb@ics.uci.edu
Information and Computer Science                 
University of California, Irvine 92715