--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 
> One thing we should clear up is that we already *have* a generic 
> comparator, C<~~>, depending on what you mean by "generic".  It can
> be 
> made to compare things however you like, according to whatever
> standard 
> of similarness you decide you want to enforce, and can even compare 
> objects of disparate types (if you tell it how.)
> 
> The way I personally have been envisioning this working is:
> 
>     $a == $b;   # compares numerifications of $a and $b
>     $a eq $b;   # compares stringifications of $a and $b
>     $a ~~ $b;   # tests equality of $a and $b
>     $a =:= $b;  # tests identity of $a and $b
> 
> Of these, I would expect that ==, eq, and =:= would almost never be 
> overloaded, because they have very specific meanings.[*]
> 
> You _could_ choose to override those == and eq for a particular
> custom 
> class, and use those for comparing equality of objects.  But since
> some 
> people will tend to want to override ==, and some will want to
> override 
> eq, it's not clear that the Perl6 community will converge on using
> only 
> one or the other, which might make things quite confusing if you're 
> using a library that has standardized on the opposite convention from
> 
> your own.
> 
> ~~, on the other hand, is meant to be overloaded to a 
> possibly-excruciating extent, and I've been assuming that it will be 
> the thing that classes most often overload when they want to test 
> "equality" of two arbitrary objects, without resorting to serializing
> 
> them via num/str.  (Using num/str comparisions to test for object 
> equality obviously only works if num/stringifying _completely_ 
> serializes the object -- which very often is _not_ what you want the 
> num/stringification of an object to do, by default.)
> 
> The proposed =:=, however, merely tests that two objects are
> identical 
> -- that is, _that they are bound to the same underlying thing_.  It's
> 
> possible for two objects to be equal, ~~wise, without actually being 
> identical, identitywise.  I don't see ever wanting to overload =:=,
> and 
> it's unclear if it should even be allowed.

It has been pointed out once already that we already talked about this,
and I for one am in favor of the general version of it.

The original discussion posited an "adverbial comparison", viz:
C<$a eq:ref $b>. Which, looking at your proposal, is very close to
C<$a =:= $b>, because I'm reading that as "equals, under assignment".

Likewise, I could argue that it be called C<=:\> (the "disgruntled
muppet" operator?) since that reflects the "equals, under reference"
symbology. But that's yucky.

So: I believe that adverbial comparisons are desirable, and in fact
believe that arbitrary-sub comparisons are desirable, provided they
don't cost much.

sub budgetwise(Int $a, Int $b) { -1_000_000 <= $a - $b <= 1_000_000; }

my Int $log_rolling, Int $pork_barrel;

$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;

if ($log_rolling eq:budgetwise $pork_barrel)
  print "They cost the same, give or take a million dollars.";


> Note also that == and eq comparisions are naturally accompanied by 
> greater-than, less-than variants.  But ~~ and =:= don't really have 
> those variants, because they wouldn't make much sense.

Even inverted comparisons are suspect in junctionville.

> Having said all that, it should be noted that I'm completely making 
> this stuff up.

Finest kind.

Reply via email to