Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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.
> 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-