develooper Front page | perl.perl6.language | Postings from August 2005

Re: ~ and + vs. generic eq

Thread Previous | Thread Next
From:
Yuval Kogman
Date:
August 29, 2005 05:52
Subject:
Re: ~ and + vs. generic eq
Message ID:
20050829125211.GL18271@woobling.org
On Wed, Aug 24, 2005 at 16:57:30 +1000, Damian Conway wrote:

This is what the operators mean to me:

> 	=:=
 
The right side and the left are the same thing, in the sense that:

	$x =:= $y; # if this is true
	$x.mutating_method; # and one side is changed
	$x =:= $y; # then this will always still be true

This may describe either truely the same space in memory, or some
sort of proxying. One scenario under which I think it's OK if they
are not the same location in memory is if I have two proxy handles
into the same remote object. They represent the same object, and are
randomly interchangable in any point in the control flow.

> 	~~

Does the right side describe the left side? Is the left side "like"
what the right side defines?

This is variadic depending on the right side, WRT to the shape and
type of the right side. It's truely a smart (polymorphic, dwimmy)
match (the right side can describe any number of values) operator,
and not equality in any sense.

> 	==
> 	eq
> 	eqv
> 	equals

For all of these, The two are equal - the same value, but not
necessarily the same thing:

	$x == $y; # if this is true (assume generic equality)
	$x.mutating_method; # and one side is changed
	$x == $y; # this might not be true anymore

As I see it ==, eq, eqv and equals are overly verbose and redundant
options for checking this same property WRT to the values involved.

When we want to be truely sure that we are comparing the two values
on a certain dimension of equality (numeric, stringwise or natural
equality, as denoted by ==, eq and equals (not eqv if the previous
posts in this thread are used)) then we force it anyway.

In perl 5 when I want my code to be readable I don't say

	if (@array == @other)

because I find that confusing.

I try to remember to say:

	if (scalar(@array) = scalar(@array))

so that it's obvious I'm comparing a coercion of the array's value.

Furthermore, I find even this repulsive... What kind of scalar
value?

Perl 6 has the ability to make this obvious by using the now
standard prefixes:

	~   - as a string
	+   - as a number
	?   - as a boolean

all of which are special cases of "natural" equality.

When I say

	if (+@array == +@other)

it's more obvious that I'm treating these as numerical values
(I may be tempted to say @array.elems if i really want to be clear,
but that's besides the point).

If I say @array == @other, it's clear to someone ***WITH A PERL 5
BACKGROUND** that i'm forcing the array into numerical context, and
then comparing that instead.

I for one know that I'll always write

	if (... eqv ...)

in perl 6, to avoid my tendency to compare strings and objects as
numbers.

I deeply regret that people from other language will mock me for
having such an ugly operator, and that everyone who doesn't care
enough will use == in a way that is broken 5% of the time.

I regret most deeply of all that the amount inertia that == and eqv have is
so imbalanced and unfair, that no one will implement 'eqv' for
generic equality in their own classes, and we'll have something that
looks like 'use overload' in perl 5.

Oh well.

> Do we really need even that many???

At the risk of sounding like a broken record, i think not

-- 
 ()  Yuval Kogman <nothingmuch@woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About