[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
...at 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.
