[REBOL] Re: On mutability and sameness
From: carl:cybercraft at: 17-Jun-2001 22:12
On 17-Jun-01, Joel Neely wrote:
> 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
> ]
> ]
Yep - exactly like that.
> 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.
Agreed - I was just being lazy with my examples. (:
>> 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
Ah, but it wouldn't work like that. I used 'increase as a word to
mimic the likes of 'insert for series. This is what would happen...
a: 10 ; a points to 10
b: a ; b points to 10
a: 11 ; a now points to 11, leaving b still pointing to 10.
What this would mean though is we'd have to use...
b: copy a
with "simples" sometimes. How often? I don't know. Perhaps RT did
some tests and found that in the real world it'd have to be way too
often and considered REBOL's present way a happy compromise between
purity and practicality.
> 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!
I don't think so, since I think you mistook what I meant - or took it
too far. "Simples" would still behave just like your string example
above, it's just that sometimes more than one variable could point to
the same value.
I think this would be more consistant. Whether it'd be better or
worse for programming though, I haven't a clue. A dialect project
for someone perhaps? (:
> 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!)
Okay - will avoid. (:
> -jn-
>
> ------------------------------------------------------------
> "Programming languages: compact, powerful, simple ...
> Pick any two!" joel'dot'neely'at'fedex'dot'com
> ------------------------------------------------------------
--
Carl Read
[carl--cybercraft--co--nz]