Re: Writing Destructive Functions

[Steve Strassmann <straz@cambridge.apple.com>]

>Date: Tue, 22 Sep 1992 12:48:14 -0400
>From: jbk@world.std.com (Jeffrey B Kane)
>To: info-mcl@cambridge.apple.com, ranson@LANNION.cnet.fr
>Subject: Re:  Writing Destructive Functions
>
>
>Daniel,
>  I understand what you're point that most "good" lisp functions return a
>result, but there are a few examples where it is a waste to constantly
>have to write (setf my-var (do-something my-var))
>A great example is the "(incf counter)" type of function, where you always
>want to increment (or decrement) the counter in place.

Yes, in those cases a macro is exactly the right thing to use.

>The second important area is in string manipulation, where copying and
>creating large strings entails a significant amount of overhead.  When you
>call a string function, it seems that in MCL ( and other LISPs?) you
>always get a copy of the string, a real waste in many applications.

Can you give an example of this? I don't think MCL or any other lisp 
copies its function arguments (strings or otherwise).

>The other time this becomes important is when I need to alter the head of
>several lists passed to my functions.  If I am changing (i.e. adding
>something to) the head of a single list, I can just return that list... no
>problem, but If I have to do this with several lists that are passed as
>parameters I run into a lot of problems.
>
> ...
>You get the idea.  I could use macros but, having been burned many times
>in the past (especially in C) I would much prefer to write real functions.

There's an even more serious burn you'll get by writing code like this.
Suppose A and B point to the same list. There's no way you can bash
A to make it point somewhere else, and have B follow along automatically,
unless you have an extra layer of indirection. It sounds like you
are storing your lists in global variables, and you want all your code
to access these lists only through their global names.

This sort of programming style is just bad news. Functional programming
lets you separate *what* you do from how you *name* the result. That
gives you the freedom to use anonymous and local variables as well
as global ones. This in turn makes your code far more clean, modular,
and portable. Try it our way, I think you'll like it!