[REBOL] Re: On mutability and sameness
From: agem:crosswinds at: 6-Jun-2001 17:11
Hi Joel, Colin, Ladislav, Scott
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 06.06.01, 13:55:38, schrieb Joel Neely <[joel--neely--fedex--com]> zum
Thema [REBOL] Re: On mutability and sameness:
> 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.
<snip>
> Of course, I'll be grateful for any explanations that anyone
> can offer to reduce my level of surprise in the future! ;-)
Me too tries it :)
<snip>
> 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,
they are
> >> 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
<snip>
> 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.
yes
> 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.
It is typical for set-path-expressions. But
> 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").
There are scalars and references. References have the behavior
of scalars for copying, but references reference!!
they are like internal telephone-numbers.
So if you copy a telephone-number and copy it for me,
and i call with it, we both call the same person.
Same with references to series or objects.
Scalars are copied, but they are »self-containing«.
If you photocopy me an telephone-number and i paint on the paper,
your paper does not change.
Same with pairs, tuples ..
so if you use a/b/c , rebol gets a/b, copies it, but its a reference!
So changes apply to the same »person« as with the old a/b.
Then it does the-copy/c . You don't notice the copy between.
if you use a/date/day, rebol gets a/date, copies it,
but its a scalar! »self-containing«. So the conection to the original
a/date is lost.
Then with this copy it does the-copy/day.
>> ;scalar copies
>> a: now
== 6-Jun-2001/17:53:46+2:00
>> b: a/date
== 6-Jun-2001
>> b/day: 7
== 7
;different!!
>> a
== 6-Jun-2001/17:53:46+2:00
>> b
== 7-Jun-2001
>> ;reference references, changes the same
>> a: context[date: context[day: 6]]
>> b: a/date
>> b/day: 7
== 7
>> ? a
A is an object of value:
make object! [
date:
make object! [
day: 7
]
]
>> ? b
B is an object of value:
make object! [
day: 7
]
AFAIK Rebol has only the distinction of this two,
so there is not to much to remember?
Check if its a series? Or an object?,
otherwise it should be copied by value.
personal rule is
»self-containing if it fits in ~8 byte and is not like a string«
BTW i think Ladislav creates some confusion with his »immutable«.
I think what he means is: functions get always copies
of their argument. If you pass a reference, you can modify
the same »person« like with the original, »mutable«.
if you pass a scalar, it gets copied..
so a function can not modify this arguments.
BTW poke has to return a copy when poking to scalars,
to avoid an exception.
Pathes on the other hand are not exactly like functions, so they
can modify parts.
Hope this makes sense
> -jn-
-Volker
