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

[REBOL] Re: On mutability and sameness

From: kenneth:nwinet at: 16-Jun-2001 22:30

Thanks Joel,
> > I seem to be confused by what I thought to be a very simple > > concept. ...memory [has] two or three attributes; value, > > address and perhaps bit-width which can be ignored for now. > > Bear in mind that we're talking about REBOL values, not > computer memory. REBOL values have type, and what/how REBOL > does with a value is influenced by its type.
It was always on the fringes (of my feeble mind.)
> > All variables are either direct or indirect addressed > > regardless of the language, but I don't think that is even > > germain to this issue. > > IMHO that *is* the issue.
My bizarre thought process always dismisses the obvious, you'll get used to it. ;-))
> > equal? is defined as "Returns TRUE if the values are equal." > > > > Which simply means regardless of where it is stored the bits > > are the same (I would think.) > > EQUAL? tests whether *content* is the same, regardless of the > data type; in the case of a reference type (your "indirect > addressed" case) that may require following the reference to > the actual content.
I think we are saying the same thing here. The reason I refer to bits is that regardless of type at some point a test of equality has to test bits of a value that have been converted to the same format/type (whatever is done internally.)
> > same? is defined as "Returns TRUE if the values are > > identical." > > Well, it's not the first time the on-line help favors brevity > over clarity and completeness.
Ain't it the truth! (universally)
> > Here's my confusion. I assume that equal? and same? are not > > aliases for the same function. > > You are correct. They are not. > > > The only meaningful distinction I can come up with is that > > identical means at the same address. > > Only if there's an "address" involved... see below.
Forgive my blockheadedness but address is always involved somehow, but I accept your explanation about same? giving the same result as equal? for non-referenced types.
> > a: 1:30 > > b: 1:30 > > same? a b ;==True > > > > ...confuses the hell out of me! Does anyone have an > > explanation?
[c code paraphrased (and be kind, I don't do c)...]
> char *a = "Hello!"; > char *b = a; > char c[] = {'H','e','l','l','o','!','\0'}; > a == b: yes > a == c: no > strcmp (a, b) : yes > strcmp (a, c) : yes
which is exactly as I would expect, but I think your example would correspond more to a Rebol version as this: a: 2:30 b: a c: 1:30 + 1:00 which point... same? a c ;=True ...varies with the... a==c: no Which is what confuses me. ...the rest would be the same (where strcmp would correspond to equal?)
> REBOL assumes that we are more interested in data than in > mechanism, so EQUAL? always tests equality of data. For > reference types (e.g., any series) EQUAL? looks *through* > the reference to the data and checks for equality, while > for non-reference types (e.g., integers or times) EQUAL? > looks directly at the data and checks for equality.
I find equal? to be predictable and correct given my limited understanding of Rebol.
> For reference types, SAME? looks *at* the reference itself > to see if the references are the same. For non-reference > types (e.g., integers or times) there are no references, so > SAME? looks at the only thing it can -- the data values. > > Hope this helps!
It does! Assuming of course, someone doesn't change the rules on me later. Which begs the question is there a referenced? vs. non-referenced? type function? Ken.