I really like this idea, but there is one minor niggle that would mean a big impact on string comparision:

Two strings can easily be recognized as "non-equal" in the 8-bit non-unicode, non-locale-contaminated world, if their lengths are different. If string comparision is upgraded to always return the first location of divergence, this means that the early-out test for string equality will not work anymore, which would be a shame for the common case of testing for strings being not equal. I'm not sure how Perl tests for equality of unicode strings, respectively if there are unicode code points that are considered equal even if they have differing binary encodings, and the same for locale-infested strings. If Perl does a simple binary comparision of strings, then the same argument holds true there, if the early-out option doesn't hold for unicode strings, then perl would only incur the the hit for plain 8-bit strings - but I guess that's still the majority of Perls string comparisions.

The simple solution would be available if the string equality operators knew about how their result would be used - in boolean or other context. But I'm not sure if there is such a thing as "boolean context" in Perl5 and if it gets propagated down to the operators at all.

#The result of the equality check is used in "boolean context"
if ($foo ne $bar) {
  print "Mismatch!";
};

#The result of the equality operator is used in "other context":
my $diff_start = ($foo ne $bar);

#The result of the equality operator is also used in "other context":
if (my $diff_start = ($foo ne $bar)) {
  print "Mismatch after $diff_start";
};
[download]

Update: An idea floating around the CB (floated by castaway and demerphq) is to store a "lazy" comparision value which would defer the string scan to when the (numerical) value is actually used. I really like this idea but I fear that it will conflict with the special string variables like lvalues and $1, as these get overwritten at the most unfortunate times - and adding an additional reference "just in case" and thus preventing string reuse seems like a bad trade in most cases, as this will mean that a new SV needs to be allocated when an old SV could have been reused...

If you'll check wantarray, you'll find that there is such a thing as boolean context in Perl 5. I don't know whether operators see it though, but there is no reason that they couldn't.

UPDATE D'oh. I meant Want, not wantarray. I shouldn't post before I wake up. :-(

Hi,

While this is a neat idea, I think Perl 6 has a better return value of ineq ops. They will return something that is a boolean, but also retains the value from one of the operands (I think it is the right). This will allow you to do wonderful things like:

While reading this, however, I wonder what would be the best way to locate the divergence point in a pair of strings. Here is what I came up with off the top of my head. I guess it would be more efficient to use substr to iterate over and compare each character, but I am too lazy for that.

#!perl -l

sub firstdivergence {
    my $diff = $_[0] ^ $_[1];
    $diff =~ /[^\x00]/g;
    pos $diff - 1
}

sub lastdivergence {
    my $diff = $_[0] ^ $_[1];
    $diff =~ /[^\x00]\x00*$/g;
    pos $diff - 1
}

print firstdivergence 'axcd', 'abced'; # prints 1
print lastdivergence 'axcd', 'abced';  # prints 4
[download]

Ted Young

I doubt perl will be changed to support such behaviour, since it is very rarely required and the information can quite easily be found by other means.

Here's one way to do it:

  ($s1 ^ $s2) =~ /[^\0]/ and return $-[0];
[download]

Hugo

Except, of course for

$s1 = "\0";
$s2 = $s1 x 2;
my $diff_pos = ($s1 ^ $s2) =~ /[^\0]/ ? $-[0] : undef;

print defined $diff_pos 
      ? "diff_pos says the strings differ at $diff_pos\n" 
      : "diff_pos says the strings are equal.\n";
print $s1 eq $s2 
      ? "and Perl says they are equal\n"
      : "and Perl says they are not equal\n";
[download]

C.

Two comments. First, this would break some existing scripts, which use the numeric value of a comaprision (for example someone might enumerate the negative numbers in a list like this: sub num_negatives { my $n = 0; $n += $_ < 0 for @_; $n; }. Secondly, this might slow down perl as the C library does not have a string comparision function that finds the offset of the first difference, so perl would have to implement it alone.