Fri, 6 Apr 2001 10:45:00 +0200, Alex Martelli <aleaxit at yahoo.com> pisze:
> If some place after the call you had for example a loop such as
> DO 10, I=1,3
> then the loop's body would 'of course' now be executed four times,
> for example.
>
> We _don't_ really want this, do we? Numbers *had better* be
> completely immutable objects -- programming becomes a funny
> game indeed if the actual values of numbers start changing
> from under our feet.
I would say that if numbers were immutable, then using a numeric
literal would have to allocate a fresh object each time, otherwise
the semantics would be too confusing, if well defined at all.
Immutability allows unrestricted sharing of values which look
the same. For immutable objects generally only '==' matters, not
'is'. Deep copying becomes equivalent to all kinds of shallow copying
and to rebinding a reference. Passing by value becomes equivalent to
passing by reference.
In an immutable world the 'boxes' and 'post-it tags' paradigms are
unified - to the point that some people are confused and believe
that Python works according to the 'boxes' paradigm, until they leave
the immutable world and want to observe mutation of an integer. They
can't create a reference to a mutating integer, because it was not
the integer which was mutating, only the object which contained it...
When a language with 'post-it tags' semantics wants to express
boxes with changing contents, it can do it in two styles: either
introduce a boxing mechanism for individual objects (this is what
SML and Haskell do), or pack multiple objects into some structures
with mutable contents (this is what Python and OCaml do). Either of
these styles can simulate the other one.
--
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4