On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs of == and eq, but I don't know what
to suggest instead (we're running short of combinations of = and : !))
So there are three basic kinds of comparison: whether the variables
are the same (different names, but naming the same thing); whether
the values are the same (deep comparison, i.e. recursively all the
way down in the case of nested containers); and in-between (shallow
comparison, i.e. we compare the top-level values, but we don't work
out *their* values too, etc., the way a deep comparison would). If
I've got it right, this is what =:=, eqv, and === give us,
respectively.
(When I say "value" I'm thinking of everything that makes up the
value, such as type (so the number 3 is different from the string
"3"), or details like the encoding for a string, etc.)
Examples:
@x=<foo bar>;
@y=<foo bar>;
$a=[1, 2, [EMAIL PROTECTED];
$b:=$a;
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $b; #true, same variable with two names
$a === $b; #true _/ $b just another name for $a,
$a eqv $b; #true \ so comparable at all levels
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements therefore same values
$a =:= $d; #false, different variables
$a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are
different refs
$a eqv $d; #true, values of @x and @y happen to be the same
(Of course, @x eqv @y, @[EMAIL PROTECTED], but not @x=:[EMAIL PROTECTED])
Note that if $i=:=$j, then $i===$j; and of course if $i===$j, then $i eqv $j.
OK, looking at S03 again, that still isn't correct. I think my =:=
and eqv are all right, but I don't understand exactly what === is
supposed to do, or why it's useful. And how do I do my
"shallow-comparison" above?
(One [1,2] is as good as any other [1,2] -- what's the use of ever
having them not compared as the same? I can see maybe for =:=, since
something that doesn't have a name cannot, by definition, have the
same name as something else... although even there, it arguably makes
sense to consider equivalent anonymous values as "bound" to the same
place. There's only one unique [1,2] in platonic heaven, I'm just
mentioning it directly instead of dropping a name.)
-David
