[EMAIL PROTECTED] wrote:
>
> On 1/6/2000 at 9:24 AM [EMAIL PROTECTED] wrote: {{
> The specifications for
> other languages, such as Python, specifically state that certain
> data types are immutable, in the sense that one cannot modify a
> value, but only construct a new one.
> }}
>
> So in terms of Pascal and C, "constants" would be immutable datatypes?
>
Sort of. I tend to think of "const(ant)" as specifying that the
identifier is immune to assignment, regardless of the type of data
involved.
A better example might be to say that array names (in c) can be
understood as immutable pointers.
>
> And, although it looks and feels like we are changing the value of A
> with something like
>
> >> a: 1
> >> a: 2
>
Here's another example of ambiguity in terminology (don't worry;
I won't climb on the soapbox -- this time! ;-)
In your example above, what is changing is the word-to-value
association of 'a. OTOH, that fragment does NOT modify the 1.
>
> And Ladislav is saying that we are really unsetting A from the
> immutable integer value 1 and resetting to another immutable integer
> value, 2 (or EX-changing one value for another).
>
> The word is mutable, but the integer value is not?
>
Exactly! (assuming you meant what I think you did)
To see this in action, consider the following cases:
a: 1
b: a
somefunction a
print b
We'd expect to get an output of 1 (ignoring dirty tricks, such as
having the body of 'somefunction assign a new value to 'b, etc.)
But, in contrast, it's easy to have:
a: "1"
b: a
someotherfunction a
print b
with an output other than "1". For example:
someotherfunction: func [s [string!]] [append s "-NOT!"]
because 'a and 'b refer to the same string, and the function
above is changing the string itself, without regard for which
reference is used to get at it.
HUMOROUS HISTORICAL ANECDOTE WITH A REBOL APPLICATION:
Early FORTRAN compilers (for example) were obsessive about applying
call-by-reference (instead of call-by-value) parameter passing
mechanisms. The effect of
J = 2
CALL FOO (J)
if FOO were defined by
SUBROUTINE FOO (IARG)
IARG = IARG + 1
RETURN
END
was that J would now contain 3. What got passed to FOO was the
address of J, so that FOO could manipulate the contents of that
address. (Remember the value-vs-container discussion.)
To save memory, all literal values in a program (compilation unit)
were translated to references into a constant pool, with only one
occurrence of each literal. Uses of those literal values were
translated into references to the corresponding addresses in the
literal pool -- essentially creating an un-named variable for each
distinct numeric literal.
The combination of the above two design decisions led to the
following surprise -- after executing
J = 2
CALL FOO (2)
K = 2
J and K would both contain 3! Because of the implementation
choices, we have a mutable integer literal!
Later versions of the compiler were smarter about this situation,
and generated code with less-surprising behavior. Subsequent
languages followed suit, and we have had generations of
programmers who think that literal values are immutable.
Now comes REBOL, whose strings are mutable, in which we can say
b: [a: "" append a "surprise" print a]
do b
do b
to have history (somewhat) repeat itself.
-jn-
