[REBOL] Re: On mutability and sameness
From: joel:neely:fedex at: 16-Jun-2001 8:33
Carl Read wrote:
> > So... Imagine we're designing such a language. What should
> > our SAME-DATA? function do if given two non-sharable values?
> > I can only think of three alternatives:
>
> > A) Throw an error...
>
> > b) Be strict and return FALSE...
>
> > c) Be generous and test EQUAL?...
>
> > I believe REBOL does (c)..
>
> ... I believe there is a place for a 'shared? word
> in REBOL, but not as a replacement for 'same?.
> 'shared? should compare words to see if they're sharing the
> same value, as apposed to 'same? which compares values.
>
You mean something like this?
shared?: func ['a [word!] 'b [word!]] [
found? all [
equal? type? get a type? get b
any [
any-function? get a
object? get a
series? get a
]
same? get a get b
]
]
which, I believe, passes all of your tests
>> a: 10 == 10
>> b: a == 10
>> shared? a b == false
>> a: "abc" == "abc"
>> b: a == "abc"
>> shared? a b == true
>> a: 10 == 10
>> shared? a 10
** Script Error: shared? expected b argument of type: word
** Near: shared? a 10
(and one you forgot ;-)
>> a: "abc" == "abc"
>> b: "abc" == "abc"
>> shared? a b == false
Without this last test in the spec, we'd only be testing
whether the type of A (and B) is sharable, not whether
A and B are actually sharing a value.
> But whether it's right for "simple" values not to be shared,
>
It's certainly *faster* for simple types not to be reference
types, as it cuts out one level of indirection.
> Consistancy is lost...
>
One kind of consistency is traded for another, but the overall
readability is *greatly* improved, in the general case. See
below for why.
> and it means we can't have the likes
> of...
>
> a: 10
> b: a
> increase a
> a
> == 11
> b
> == 11
>
But if you have the likes of *that*, then why wouldn't you have
the likes of
a: 10
b: a
a: 11
b
== 11
which would probably be *very* non-intuitive and inconsistent
with
a: "hello"
b: a
a: "goodbye"
b
"hello"
This exposes us to the danger of confusing mutability and
referenceability all over again, in an even more subtle way!
In addition, "magical" dereferencing of references (especially
multiple layers of them) leads to *highly* confusing/unreadable
code. Consider the horrible example of Algol 68! (And if you
don't even know about Algol 68, take my word for it that the
confusing handling of ref/deref behavior is probably a major
reason why!)
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
