[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