== and != don't work as expected

[esharris]

I read that == returns true if its operands are numerically equal.

However 'two' == 'two' executes a warn and returns a false value.

If "two" has a numeric interpretation, the preceding expression should return true, because numeric equality is reflexive.

If "two" does not have a numeric interpretation, then, IMHO, the preceding expression should die. Why did the developers decide that 'two' == 'two' should warn and return false?????? Is there a Pragma that will force such an expression to die? Under the current interpretation, it is difficult to detect errors in web applications. I.e., it can be the source of an obscure error.

[davorg]

$ perl -lwe 'print "two" == "two"'
Argument "two" isn't numeric in numeric eq (==) at -e line 1.
Argument "two" isn't numeric in numeric eq (==) at -e line 1.
1

So it returns a true value.

But that's because Perl tries to convert strings to numbers in order to do the numeric conversion. "two" has no obvious numeric equivalent so Perl uses zero.

Perl rarely dies because it finds data in the wrong format. It tries hard to do what it thinks you want to do. This is usually seen as a feature.

If it's essential that your program only compares actual numbers, then you should check them before you do the comparison.

[Limbic~Region]

esharris,
I can't reproduce your problem

$ perl -Mstrict -Mwarnings -e 'print "foo\n" if "two" == "two";'
Argument "two" isn't numeric in numeric eq (==) at -e line 1.
Argument "two" isn't numeric in numeric eq (==) at -e line 1.
foo

The warning is useful since you should be using eq there, but it does indeed return true because those strings do have numerical equivalence when the treated that way.

[GreyGlass]

If you prefer fatal treatment, you can:

use warnings FATAL => qw(numeric);

Of course if you like something else, you can always get it by doing your favorite thing in a
$SIG{__WARN__} handler.

[esharris]

My bad. I should have posted a coded example.

I was confused when 'two' != 'one' returned a false value in my program. I agree that 'two' == 'two' returns a true value.

I understand that this semantics is consistent.

When developing a complex Perl program, I would prefer for 'two' != 'one' to die, rather than return false. IMHO, the current behavior is not always desirable.

Sorry.

[davorg]

Are you sure that you don't just want the string comparison operators - eq, ne, etc?

[PodMaster]

So use fatal warnings instead. `perldoc perllexwarn'

C:\>perl -Mwarnings=FATAL,all -e"print 1 if shift == shift" foo foo
Argument "foo" isn't numeric in numeric eq (==) at -e line 1.

C:\>perl -we"print 1 if shift == shift" foo foo
Argument "foo" isn't numeric in numeric eq (==) at -e line 1.
Argument "foo" isn't numeric in numeric eq (==) at -e line 1.
1

[TomDLux]

The numeric value of the string "two" is zero (0)

The numeric value of the string "one" is zero (0)

Comparing the numeric values of the two strings, "two" and "one", shows they have the same numeric value. This is identical to the numeric value of "potato" ( and even of "potatoe" ), "Zambia", "infinity" and "TomDLux".

If you want to compare the strings, use '=='. If you want to use numeric comparisons on strings, make sure they contain numbers.

[Vautrin]

Perl is a weakly typed language. Unlike C, for isntance, if you wanted to create a number then a string you could do:

my $string = 1;
$string = "code";  # we can reuse the variable name

versus:

char* mystring = "this is a C style string";
int   myInt    = 1; // Can't reuse variable names
                    // plus need to declare the type

You will find this paradigm called DWIM (Do What I Mean) by a lot of people. Basically, part of the price we pay for DWIM is that the interpreter doesn't choke and die on ambiguities, but makes a best guess.

[chromatic]

Perl is a weakly typed language.

<mini_rant>

No, it's not. It just doesn't associate the type with the name, as you might expect. Try coercing a hash to an array in place or treating a scalar as an array, for example.

C's typing system is only slightly more advanced than bare assembly code.

</mini_rant>

[Vautrin]

Out of curiousity, can you name some weakly typed languages with your definition?