[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Side effecting constants inside functions
- To: GSB@MIT-MC.ARPA
- Subject: Side effecting constants inside functions
- From: Tim McNerney <TIM@MIT-MC.ARPA>
- Date: Sun, 25 Aug 85 03:15:02 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of Tue 20 Aug 85 03:51:17 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
Date: Tue, 20 Aug 85 03:51:17 EDT
From: Glenn S. Burke <GSB at MIT-MC.ARPA>
Date: Tue, 20 Aug 85 02:52:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
In CLtL, I can't find any mention of the issue of side effecting
internal constants. In Maclisp [interpreted code], NIL, Zetalisp
[both interpreted and compiled code], and presumably most Common
Lisp implementations, the function:
(defun withdraw (amount)
(let ((balance '(1000)))
(decf (first balance) amount)))
acts much like a lexical closure with a local state variable.
Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This
behaviour has always bothered me. Is this rather questionable style
condoned by Common Lisp?
This extremely questionable style is considered "an error" in both
Maclisp and NIL, which take the view that such constants are
permissible to be made read-only, and potentially made EQ to other
constants which are EQUAL.
This would be a good position for Common Lisp to take, my point being that
this is not written down anywhere (not even in the NIL manual). The rest
of my letter merely supports this position by pointing out some issues that
would have to be dealt with if this were NOT considered an error. Perhaps
I did not make myself sufficiently clear.
In NIL when the code is compiled this does not work, as such
constants in compiled code in NIL are currently ALWAYS read-only...
Glenn S. Burnout
Had you actually compiled the above function and tried it out, you would
have noticed that the NIL compiler produces code with exactly the same
behavior as Zetalisp, and furthermore, that the bogus state variable is,
despite your claims, preserved across COMPILE.