[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
