[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mutable/immutable
| Date: Thu, 30 Sep 93 17:07:05 -0400
| From: Michael R. Blair <ziggy@martigny.ai.mit.edu>
|
| Is this an oversight or is there some subtle rationale behind the
| following:
|
| literals are constants and therefore immutable.
| other constructed composite data are mutable.
|
| There is/are no predicate(s) to test mutability.
|
| I think (tell me if I'm wrong) that constants are immutable to allow
| sharing of constants. Predicates to decide mutability would require
| to maintain run-time information about mutability -- which could be
| expensive in some implementations.
Some implementations don't support immutability.
But the issue of immutability is both a "want to compile constants into
(immutable) code representations, which might be shared" and "don't
give the user a nasty surprise."
Consider:
(define (a)
'(1 2))
The result of (a) is immutable. If you modify this constant, which only
has one instance, you've changed the code...the next call to (a) will
return the mutated value. Maybe. Welcome to the wonderful world of
self-modifying code...
A system which detects mutation of immutable objects prevents this error:
% psi
> (define (a) '(1 2))
#<unspecified>
> (set-car! (a) 'b)
Error -- set-car!: object is immutable: (1 2)
> ^D
| Also, some systems use Scheme itself to compile the Scheme code. Those
| systems would need to be augmented by procedures like
|
| (immutable-cons <obj1> <obj2>)
| (list->immutable-vector <list>)
|
| etc. (The ``constants'' of the user program are not ``constant'' in
| the compiler.)
And is this ever a headache.
Regards,
Dak
--
David A. 'Dak' Keldsen of SoftQuad Inc. email: dak@sq.com phone: 416-239-4801
"By golly, no monsters are going to get *us* tonight!
Wither and die, bloodsucking freaks of nature!!" -- Calvin and Hobbes
[commentary on debugging? -- Dak]