[REBOL] Re: On mutability and sameness
From: joel:neely:fedex at: 6-Jun-2001 7:55
Hi, Colin and Ladislav,
First of all, let me restate my underlying goal: to have a
robust mental model of REBOL that allows one (i.e, me) to
understand what a piece of code does BY READING THE CODE,
and NOT having to depend on "let's try it out and see what
happens". I think it's obvious that the more exceptions one
has to memorize, the more difficult it is to construct and
use such a mental model.
As I don't have time personally to try out all possible REBOL
utterances to observe their effect, I'm grateful when others on
this list provide descriptions of exceptional behavior. I try
to return the favor when possible.
Ladislav Mecir wrote:
> Hi Colin,
>
> > No worries. I think the only point I was making was that
> > Joel *may* be mistaking a bug for an esoteric, and
> > hard-to-model, feature.
> >
Ummmm. I think I need to clarify. I'm not asserting either,
so I don't think I've made a mistaken assertion.
I deliberately avoided the word "bug": in the absence of a
published spec for what REBOL is *intended* to do, all I can
say is, "That's surprising to me!" when I encounter behavior
which I didn't expect.
Of course, I'll be grateful for any explanations that anyone
can offer to reduce my level of surprise in the future! ;-)
> I am pretty sure, that the feature you are describing is not
> a bug. The reason for the behaviour is pretty simple. Rebol
> values of type TUPLE! DATE! INTEGER! and some other types
> are immutable ...
>
Part of my point was that the above assertion is no longer
strictly true (I believe there's been a change at some point),
at least with regard to DATE! values. Comparing
>> a: make date! [2001 6 6] == 6-Jun-2001
>> a/day: 7 == 7
>> a == 7-Jun-2001
with
>> a: make object! [x: 17 y: 42 show: does [print [x y]]]
>> a/show 17 42
>> a/x: 19 == 19
>> a/show 19 42
it seems reasonable to conclude that the first transcript
demonstrates changing a component of a date "in place", which
would mean that DATE! values *are* mutable. However,
>> a: make date! [2001 6 6] == 6-Jun-2001
>> b: a == 6-Jun-2001
>> a/day: 7 == 7
>> a == 7-Jun-2001
>> b == 6-Jun-2001
provides evidence that DATE! is not a "reference" type.
> try-to-change2: func [
> 'value [word!]
> ] [
> either (get value) = 1.1.1
> [set value 1.1.2]
> [set value 1.1.1]
> get value
> ]
>
> a: 1.1.2 ; == 1.1.2
> try-to-change2 a ; == 1.1.1
> a ; == 1.1.1
>
> Here it looks like I succeeded to change the supplied
> value 1.1.2. In fact I didn't change the value 1.1.2. I
> computed a new value 1.1.1 instead and stored it to the
> supplied word 'a , which now contains a different value
> than before.
As you correctly point out, the old value of A has been
*replaced*, and not mutated. But the key to seeing this
(by reading the code and not by trial-and-error) is to
know that the SET operates on A (the value of 'VALUE) and
not on the value of A (the value of the value of 'VALUE).
The same would have applied to any use of A: of course.
> The same effect I can achieve using a set-path:
>
> a: 1.1.2 ; == 1.1.2
> a/3: 1 ; == 1
> a ; == 1.1.1
>
Here our interpretations differ. By analogy with
>> a: make object! [x: 17 y: 42 show: does [print [x y]]]
>> a/show 17 42
>> a/x: 19 == 19
>> a/show 19 42
and with
>> a: [x 6 y 7 z 42] == [x 6 y 7 z 42]
>> a/x == 6
>> a/x: 9 == [x 9 y 7 z 42]
>> a == [x 9 y 7 z 42]
it seems reasonable to understand a SET-PATH! as mutation; it
seems to change an element of a composite structure "in place",
rather than computing and returning a modified copy of the
entire structure.
This is why I found the following behavior to be inconsistent:
>> a: now == 6-Jun-2001/7:49:06-5:00
>> a/date/day: 7 == 7
>> a == 6-Jun-2001/7:49:06-5:00
>> a/day: 7 == 7
>> a == 7-Jun-2001/7:49:06-5:00
The effect of A/DAY: appears to be typical for SET-PATH!
behavior -- a component of the original structure seems to
have been modified in place. However, the effect of A/DATE/DAY:
seems to involve a copy-and-modify behavior that is *NOT*
typical for SET-PATH! expressions.
Hence, an exception that simply must be memorized (at least
until someone provides a more comprehensive mental model of
*why* such an inconsistency is "natural").
-jn-
