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

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