RFC eq and ==

[Pedro Larroy]

Would it be a good idea to make ==, and other numeric comparators polymorphic
so they can be used also for string comparisons? Or the will is to keep eq,
gt and the others. (not very nice emho).

Regards.
--
Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org

Software patents are a threat to innovation in Europe please check:
http://www.eurolinux.org/

[Chromatic]

On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote:

> Would it be a good idea to make ==, and other numeric comparators polymorphic
> so they can be used also for string comparisons?

How does the compiler know which is which?

Is "10" a string? Is it a number? Is "10base-T" a string? Is it a
number? Is an object with overloaded stringification and numification a
number? Is it a string?

I don't know a good heuristic for solving these problems. If you have
one, it's worth considering though.

-- c

[Pedro Larroy]

I thought perl internally would know. At least in perl5 it has to know
somehow, since you can $var++ when is numeric and also when it's a
string, and behaves different in each case.

[Luke Palmer]

Pedro Larroy writes:
> Would it be a good idea to make ==, and other numeric comparators
> polymorphic so they can be used also for string comparisons? Or the
> will is to keep eq, gt and the others. (not very nice emho).

It was decided long ago that the distinction between == and eq is going
to stay. En mi humilde opinión, the idea is not archaic, but quite
modern. Or postmodern Larry would say, though I don't really understand
what that means.

Since scalars are polymorphic, their operations must not be. The
problem is the same as that of using + for string concatenation (which
has been proposed far too many times). A big part of Perl is the
ability to do:

my $a = 43;
$a += 1;
$a ~= " bananas"; # 44 bananas

And the ability to keep the semantics the exact same if you happen to
put quotes around the "43"... or read it in from a file, for instance.

Admittedly, if you use == for everything, you can force string or
numeric comparison this way:

if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string

But it's been pointed out:

if +(some($big+%nasty«expression»)) == +$b {...}

Now it takes three, maybe four re-scans to figure out that it's a
numeric comparison. Kills readability.

Fortunately for the generic programmer there's a generic equality which
returns true when objects are the same type (or almost the same, like an
integer and a string that looks like an integer), and false otherwise.
Larry called it "equal", though "equals" seems much, much better.

if $a equals $b {...}

There's your "polymorphic" equality, if you will. I'd be wary of using
it often, however.

Luke

[Chromatic]

On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote:

> I thought perl internally would know. At least in perl5 it has to know
> somehow, since you can $var++ when is numeric and also when it's a
> string, and behaves different in each case.

True. Perl 5 scalars do keep track of the context in which you've used
the data they hold. If you treat a scalar like a number, it'll behave
like a number. There are some wacky corner cases, though, where you see
side-effecty action at a distance. (I remember running across this at
least twice, though I don't remember specific examples. DWIM usually
works well.)

As Luke suggests, there's also programmer clarity to consider. If
determining how to compare depends on how you've used the variables to
compare, is it harder to understand the code? The solution for an API
designer may be "be very careful, then!" but I'm not sure a language
designer has that luxury.

-- c

[Rod Adams]

Luke Palmer wrote:

>Admittedly, if you use == for everything, you can force string or
>numeric comparison this way:
>
> if +$a == +$b {...} # numeric
> if ~$a == ~$b {...} # string
>
>

Hmm.
In my head, I would expect == to have implicit numification on the
operands (unless user-overloaded to something else, but that's
different). In turn, I'd expect eq to have implicit stringifies.

Therefore I'd expect the +'s to redundant in the first example.

I'd then expect the second example to first convert $a and $b to strings
because of the ~'s, then, because it sees the ==, it would numify those
strings and do a numeric compare.

Are my expectations misaligned here?

-- Rod

[Luke Palmer]

Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a
polymorphic operator.

You're correct in terms of the current (and hopefully continuing) state
of things.

Luke

[Rod Adams]

Luke Palmer wrote:

>Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a
>polymorphic operator.
>
>You're correct in terms of the current (and hopefully continuing) state
>of things.
>
>

Went back and re-read your first post, and that is indeed what you were
saying, I just read it too fast.

I'd be seriously annoyed if eq went away. It's one of those things that
makes Perl Perl. It's up there with the postfix if.

~$a == ~$b
feels too much like:
Cast(String, $a).Compare(Cast(String, $b))

-- Rod

[Juerd]

Luke Palmer skribis 2004-05-17 14:54 (-0600):

> Admittedly, if you use == for everything, you can force string or
> numeric comparison this way:
> if +$a == +$b {...} # numeric
> if ~$a == ~$b {...} # string

And $a :=: $b could be written as \$a == \$b. Oh, hm.

It does sound kind of attractive to me, because it's a bit like

lc $a eq lc $b

Juerd

[Austin Hastings]

> -----Original Message-----
> From: Rod Adams [mailto:r...@rodadams.net]

> I'd be seriously annoyed if eq went away. It's one of
> those things that makes Perl Perl. It's up there with
> the postfix if.
>
> ~$a == ~$b
> feels too much like:
> Cast(String, $a).Compare(Cast(String, $b))
>

But it's far easier to convert polymorphic == into an eq
macro than to convert eq into an == macro. :-)

=Austin

[Simon Cozens]

chro...@wgz.org (Chromatic) writes:
> Is "10" a string? Is it a number? Is "10base-T" a string? Is it a
> number? Is an object with overloaded stringification and numification a
> number? Is it a string?
>
> I don't know a good heuristic for solving these problems. If you have
> one, it's worth considering though.

Use =~ for all these kinds of comparison. No, I'm not being facetious, at
least not intentionally.

--
At Friday's meeting I did get a chance to call a spade an earth-moving
bloody implement of damn-and-blasted wood and bastard metal
construction.
- Red Drag Diva

[Aaron Sherman]

On Mon, 2004-05-17 at 17:13, chromatic wrote:

> As Luke suggests, there's also programmer clarity to consider. If
> determining how to compare depends on how you've used the variables to
> compare, is it harder to understand the code?

To be specific, what does:

my $a = foo();
my $b = bar();
if $a == $b {
baz();
}

mean? Is it a numeric comparison? String? What?

The reason we need == and eq is to allow the programmer to specify which
behavior they wish. It really is that simple.

Now, that brings us to an ugly little bridge for higher level objects,
of course. What does it mean to override infix:== or infix:eq and which
would you override when?

It's going to have to be a matter of convention, but I would suggest
that things which "feel" numeric should provide an == and things that
"feel" stringy should provide an eq, but not both unless they are
actually different in some relatively obvious way to the casual Perl
programmer.

That means that while a matrix class might define ==, it probably should
not defined eq (though it might be serializable in some way that makes
eq possible through conversion). Similarly, a class that represents a
DNS zone should probably provide an eq, but not ==.

All that make sense?

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback