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

[REBOL] On mutability and sameness

From: joel:neely:fedex at: 5-Jun-2001 8:45

Just another bit of REBOL "particle physics"... At one time (REBOL/Core 2.3?) values of type DATE! were immutable. Now they're not. Well, not exactly! But they also now don't behave as mutable reference values. ON SAME AND EQUAL: In most programming language (that make the distinction!), two values are "equal" at a given moment if they can are equivalent for some useful set of purposes (at that moment!) Two values are "same" if they are *always* equivalent for *all* purposes. For a real-world example, if Ladislav and I win a contest and are each awarded a Swiss bank account containing 1000 francs, we have "equal" account balances (at the time of the award). Subsequent deposits and/or withdrawals will probably render Ladislav's balance and my balance "unequal". OTOH, if Carl and Cindy win a contest and are awarded a *joint* Swiss bank account containing 2000 francs, they have the "same" account balance. No subsequent deposits and/or withdrawals can make their balance(s) unequal, as they are the "same" balance. ON MUTABILITY: Mutable values can be modified "in place", while immutable values cannot. One can replace a resistor in a discrete circuit breadboard without changing the identity of the circuit or its other attributes (location, owner, etc.) One *cannot* replace a resistor in the CPU I'm using to type this email, but can only unplug the CPU and plug in a replacement CPU. The breadboard is mutable; the CPU is immutable. ON REFERENCE: Reference values are "stored elsewhere" and represented by some form of identifier, while non-reference values (AKA primitive , "elementary", or "atomic" values) do not need that level of indirection. Reference values are typically sharable, while non-reference values are often not sharable. Life becomes a bit simpler if only sharable reference values may be mutable, because the following general rules apply: For mutable values, same IMPLIES equal. For immutable values, same IS EQUIVALENT TO equal. But, as we all know, sometimes REBOL isn't simple! ;-) SIMPLE CASES IN REBOL: INTEGER! values are non-reference, immutable values.
>> i: 1 + 1 + 1 + 1 == 4 >> j: 6 - 2 == 4 >> same? i j == true >> equal? i j == true
STRING! values are mutable reference values (as are other series values).
>> r: "hi!" == "hi!" >> s: r == "hi!" >> t: "hi!" == "hi!" >> same? r s == true >> equal? r s == true >> same? s t == false >> equal? s t == true >> r/1: #"H" == "Hi!" >> s == "Hi!"
Object values are mutable reference values, but do not admit an EQUAL?ity test independent of SAME?ness (perhaps because the general case is computationally non-trivial?)
>> o: make object! [x: 17 y: 42] >> p: o >> q: make object! [x: 17 y: 42] >> same? o p == true >> equal? o p == true >> same? p q == false >> equal? o q == false >> o/x: 19 == 19 >> source p
p: make object! [ x: 19 y: 42 ] NOT-SO-SIMPLE CASES IN REBOL: Once upon a TIME! (groan, sorry ;-), the DATE! type was immutable. One *FORMERLY* could do something like this:
>> a: now/date == 5-Jun-2001 >> a/day: 6 == 6 >> a == 5-Jun-2001
Now the above sample works like this:
>> a: now/date == 5-Jun-2001 >> a/day: 6 == 6 >> a == 6-Jun-2001
making it appear that DATE! values are mutable. Perhaps, as with series values, they're mutable references?
>> a: now/date == 5-Jun-2001 >> b: a == 5-Jun-2001 >> same? a b == true >> equal? a b == true
Encouraged by our success thus far, we try the mutability test for referencehood...
>> b/day: 6 == 6 >> a == 5-Jun-2001 >> same? a b == false
Wot?!? Well, this begins to smell like the implementation technique we called "self-relative descriptors" back in the late 60's and early 70's! However, they're are more surprises! Consider this:
>> a: now == 5-Jun-2001/8:31:47-5:00 >> b: a == 5-Jun-2001/8:31:47-5:00 >> c: b/date == 5-Jun-2001 >> b/date/day: 6 == 6 >> b == 5-Jun-2001/8:31:47-5:00
Hmmm... are DATE! values not mutable?
>> b/day: 6 == 6 >> b == 6-Jun-2001/8:31:47-5:00
Yes, so perhaps /DATE does an implicit copy? How can we tell?
>> b/time/hour: 9 == 9 >> b == 6-Jun-2001/8:31:47-5:00
So, "second-level" mutability does not apply? What about first-level mutability ?
>> b/hour: 9 ** Script Error: Invalid path value: hour
** Where: halt-view ** Near: b/hour: 9
>> b/hour ** Script Error: Invalid path value: hour
** Where: halt-view ** Near: b/hour Hmmm. There is no first-class access to the time fields of a date.
>> b/time/hour == 8 >> c/time/hour ** Script Error: Cannot use path on none!
value ** Where: halt-view ** Near: c/time/hour
>> type? b == date! >> type? c == date! >> b/time
== 8:31:47
>> c/time
== none Conclusions? I'm not sure, except that I haven't figured out a simple model for what's going on with DATE! values, and therefore don't have a simple model for REBOL values in general. -jn- PS: It *does* appear that a date is a composite entity with some "refinements" that mimic simple component access, but there seems to be more to the picture. ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com