Ray Dillinger <firstname.lastname@example.org> wrote:
| Pascal Costanza wrote:
| > You bet it is.
| > Side effects are necessary for properties that change over time.
| > (A silly example: the wage of a person.) And with it comes the
| > necessity of dealing with object identity.
| Ergh. Did you even read my post? I was not questioning the value
| of mutation itself. I was questioning the value of the ability
| for mutation to change the value of some *DIFFERENT* variable
| besides the one being mutated.
In Lisp, variables per se are never mutated:
1. A variable *binding* may be mutated to refer to another object
[e.g., as with a simple SETQ].
2. The *object* a variable is currently bound to may be mutated
[e.g. as with (SETF accessor)], provided it is a mutable object.
[Some aren't. E.g., numbers & characters are immutable in CL.]
So it seems that in fact your fundamental complaint is really that
Lisp allows a mutable *object* to be simultaneously bound to two
different variables. Sorry, that's life. You can't prevent that
without preventing function calls!!
I suspect from your continuing upset at peoples's responses in this
thread that what you really might be looking is not for ordinary
applicative Lisp at all, but rather for some flavor of "linear logic"
instead, such as the "linear Lisp" Henry Baker has written about at
great length, see:
Linear Logic and Permutation Stacks--The Forth Shall Be First
Linear Lisp is a "linear" style of Lisp--i.e., every bound name
is referenced exactly once. Thus, each function parameter occurs
just once, as do the names introduced via other binding constructs--
e.g., let, let*, etc.
'Use-Once' Variables and Linear Objects -- Storage Management,
Reflection and Multi-Threading
A 'Linear Logic' Quicksort
and several others. See his archive page:
| ...because I accidentally used some set of keywords
| I'm getting a canned answer to a question which is sort of
| related to the one I asked, but not the one I asked.
I suspect that's because you asked "the wrong question". ;-}
Or equivalently, asked the question you were really interested
in using words that confused your readers, see above. [But I
could be wrong about that...]
 Since *every* function call binds the formal parameters in
the called routine to the *values* of the actual parameters
in the calling routine, any time any actual parameter in a
calling routine happens to be a variable bound to a mutable
object then there *will* be a simultaneous binding of the
mutable object to two different variables as soon as the
function call happens!! Mutation of the object in the called
routine *will* be visible in the calling routine after the
called routine returns.
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607