On Tue, Apr 01, 2003 at 06:39:24PM -0500, Miko O'Sullivan wrote:
: Of course, you can also cast the objects to change what type of comparison
: you want. So, for example, C<$a =:= $b> compares the outputs of the
: value_for_comparison methods, but C<~$a =:= ~$b> compares the numification
: of the objects, or, to get into the guts of the matter, the objects are
: evaluated in numeric context, which causes them to run their overflow
: methods for numification, which returns number objects, which then call
: their value_for_comparison methods, which return the numbers as
: represented by some string which is formatted according to some
: unambiguous rule (we already have those unabiguou rules).
The problem with this approach is that it assumes you can efficiently return
a string to be compared. I'm not sure this is even true of strings, let alone
arrays and hashes. When you write:
(1..Inf) equal (0..Inf)
I'd like Perl to consider that false rather than having a blank look
on its face for a long time. It's just a generalization of how eq and
cmp give up as soon as they see two different characters in a string.
So whatever equivalence and ordering operators we end up with, they
had better be able to do lazy comparisons of characters or elements
and give up as soon as they know the answer. In fact, they need to
be smarter than that if we also want:
(0..Inf) equal (0..Inf)
to run in finite time. Lazy arrays need to delegate the operation
to their underlying generators whenever possible.
Larry
