Mailing List Archive: 49091 messages

## [REBOL] Re: Puzzle with FIND and SELECT

### From: lmecir:mbox:vol:cz at: 10-Feb-2003 17:23

```
Hi Joel,

...
> - Why do we need SAME? at all?  One use is to distinguish mutable
>   values so that one can determine in advance whether a change via
>   one "access path" will affect what is visible via another?

SAME? is not useful for this purpose. The reason is as follows: you can find two values
that clearly aren't the same, like e.g.

a: [1 2]
b: next a

A and B are Relatives in the above sense and a mutation of A can affect B even though
A and B are neither same nor equal. For the cases like above the RELATIVES? equivalence
(in http://www.rebolforces.com/~ladislav/evaluation.html ) is better suited.

>  That
>   said, are there others?

See the applications of the IDENTICAL? function (in http://www.rebolforces.com/~ladislav/evaluation.html
).

>  Does this imply that immutable values
>   of the same type (see below) which are equal are indistinguishable?

This is a proven thing for me (in http://www.rebolforces.com/~ladislav/evaluation.html
).

> - Do we need more state into the semantic model?  Even if we accept
>   the notion that "every REBOL value is in a block...", some blocks
>   are inaccessible (e.g. blocks resulting from the load/eval/print
>   cycle at the console).  This already means that we can't take any
>   arbitrary expression and wrap it in a function without the risk
>   of changing its semantics, as in the classic REBOL-newbie koan:
>
>      >> repeat i 10 [append [] i]
>      == [1 2 3 4 5 6 7 8 9 10]
>      >> foo: func [n [integer!]] [repeat i n [append [] i]]
>      >> foo 5
>      == [1 2 3 4 5]
>      >> foo 5
>      == [1 2 3 4 5 1 2 3 4 5]

Moreover, even if we could wrap any expression in a function/block/whatever, how can
we guarantee, that any value will be in a one and only one block and not more, and that
it will be at exactly one position of the block?

>   And my proposed solution is that a DECIMAL! value and an INTEGER!
>   value should never be SAME? (even if EQUAL!) because they *are*
>   distinguishable by some means in the language (TYPE? of each).
>
>   Since RT apparently has chosen TYPE? to be a discriminator for
>   FIND and SELECT it should be relevant to SAME? at least AFAIAC.
...

Agreed.

Regards
-L
```