Newsgroups: comp.lang.lisp
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!washdc3-snh1.gtei.net!news.gtei.net!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!world!news
From: Kent M Pitman <pit...@world.std.com>
Subject: Re: Destructive Side Effects
Message-ID: <sfwd72h6swi.fsf@shell01.TheWorld.com>
Sender: pit...@shell01.TheWorld.com
Date: Sat, 17 Nov 2001 20:31:41 GMT
References: <mMxJ7.518$ul2.93525@news.uswest.net> <3215011069184765@naggum.net> <KjyJ7.723$ul2.104441@news.uswest.net> <9t6doa$436$1@rznews2.rrze.uni-erlangen.de> <eczJ7.899$ul2.122252@news.uswest.net>
NNTP-Posting-Host: sgi01-g.std.com
Organization: My ISP can pay me if they want an ad here.
X-Newsreader: Gnus v5.7/Emacs 20.7
Lines: 45

"David McClain" <bar...@qwest.net> writes:

> > don't use them! Please not too that most of CL's destructive functions
> have
> > to be used in a functional way (you have to use the return value). The
> only
> 
> Actually, this is one of the surprising things about REMF that caught my
> attention. You are correct that most often destructive operations in Lisp
> operate in a functional manner... except for REMF (and no doubt a few
> others...)

Well, from a philosophical point of view, it's generally important
that this BE destructive.  The whole point of properties is to
implement a kind of blackboard approach to programming, and the idea
of having a bunch of people working on a shared blackboard with only
copying-assignment available is pretty odd.  By reverse induction (if
there is such a thing), all plists would be always empty.

I'm not saying there's never a reason to want to spawn a separate plist,
but I don't think it's the norm.

Similarly, one doesn't have destruction-free hash tables either.

It is true that REMOVE is a possible operation on alists, but in practice
it's very rare for me to use such a thing...  You never know how long an
alist will be and it's a good way to get O(n^2) behavior if you go randomly
copying all its elements to do something.  We just saw someone here the other
day who was implementing (cdr (assoc 'foo x)) as 
(cadar (remove-if-not #'(lambda (key) (eq key 'foo)) x :key #'car))
or some such thing.  Saying that people should program in a side-effect-free
way creates situations where people do this kind of thing.

I know there are languages where this kind of thing is done routinely.
MOO does all side-effects to lists (which it implements more like vectors)
by copying.  But then, while MOO is very pleasant to program in for small
problems, it is not known for its ability to enable programmers with the
full computational speed of the underlying machine.  Lists are only second
class data in MOO, and really have no identity.

And perhaps there are FP languages that secretly do better by doing the dirty
side-effects invisibly so you don't have to see them.  Ultimately, assembly
code ALWAYS works by side-effect, after all.  Everything above the basic memory
model of the machine that suggests otherwise is an illusion.