implicit data type exchange

xiaoyafeng has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks，

I don't know implicit type exchange is a feature or a drawback of perl.In terms of me,I fall the same trap again and again ;)
Some days ago, many monks tell me oct and hex function only accept string no matter what you input. here
Yesterday,I wrote a script for fun and practice. here I found that user input 1(5 spaces before number) is equal to 1.Because of the last experience,I suspect that implict type exchange resulted in it.So I have a try:

use strict;
use warnings;

my $num1 = 4;
my $str1 = "4";
my $str2 = "     4";
print "number \$num1 is equal to string \$str2!!\n"if $num1 == $str2;
print "number \$num1 is equal to string \$str1!!\n" if $num1 == $str1;
print "string \$num1 is equal to string str2 !!\n" if $num1 eq $str2;
print "string \$num1 is equal to string str1 !!\n" if $num1 eq $str1;



__OUTPUT__
number $num1 is equal to string $str2!!
number $num1 is equal to string $str1!!
string $num1 is equal to string str1 !!
[download]

Obviously,perl will truncate all spaces before number when it treats a string as a number.No offense,I was wondering why perl develper don't add type declaration(such as num,str).At least, It will help perl beginner not falling many pitfalls like above.

I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Comment on implicit data type exchange Download Code

Replies are listed 'Best First'.
Re: implicit data type exchange by GrandFather (Saint) on Jan 10, 2007 at 08:28 UTC
Perl's transparent handling of the differences between numeric and string values is one of its major strengths. Much of my programming background is in strongly typed languages and when I first started using Perl I envisaged a lot of wasted time sorting out problems because of the lack of variable typing and checking. In fact that hasn't transpired at all. To an extent the problems you seem to be having are because you are fighting against Perl rather then letting it DWIM (Do What I Mean). The vast majority of the time Perl just gets on with business and is unsurprising - which is really surprising when you think about it! DWIM is Perl's answer to Gödel	[reply]
Re: implicit data type exchange by jbert (Priest) on Jan 10, 2007 at 09:42 UTC
Perl isn't a statically (or even strongly) typed language. It generally tries to do "something sensible" (or "Do What I Mean" - abbreviated as DWIM) with data. If you're trying to use a string as a number, it will do a string->numeric conversion (handling leading spaces and stopping at the first non-digit). This behaviour is generally useful and time-saving. One places where you may get caught out by it is in boolean true/false tests. All the following are false (nothing is printed): `print "a" if 0; print "b" if ""; print "c" if "0";` [download] the one which surprises people the most is "c" not being printed. Dynamic languages can require a bit of mental adjustment, C, C#, C++ and java programmers are used to having the compiler catch certain classes of errors. Perl will only catch similar errors at runtime (and will work around others as we've just seen). For those that like dynamic languages, the general view is that you are more productive in them (since type declarations littering your code make it more brittle - i.e. harder to change and adapt it) and that computer-checked correctness is better achieved via unit testing, to verify the dynamic behaviour. There is a well-established culture of unit testing in perl, with good modules to support it's use and most (all?) CPAN modules including a test suite. Lastly, I think perl6 will bring such (optional) type annotations to the language, but I'm not sure and don't know the details.	[reply] [d/l]
Re: implicit data type exchange by Anonymous Monk on Jan 10, 2007 at 08:42 UTC
At least, It will help perl beginner not falling many pitfalls like above. Perl beginners like you should start by reading perlintro and/or a book like "Learning Perl". Perl operators are documented in full in perlop, but here are a few of the most common ones: Arithmetic + addition - subtraction * multiplication / division Numeric comparison == equality != inequality < less than > greater than <= less than or equal >= greater than or equal String comparison eq equality ne inequality lt less than gt greater than le less than or equal ge greater than or equal (Why do we have separate numeric and string comparisons? Because we don't have special variable types, and Perl needs to know whether to sort numerically (where 99 is less than 100) or alphabetically (where 100 comes before 99).	[reply]
Re: implicit data typecast by xiaoyafeng (Deacon) on Jan 10, 2007 at 10:51 UTC
Thanks for all reply! I partly agree grand father's answer.But I still stand on my opnion.If using warning pragrma,perl should give a warning message when typing change. UPDATE:I don't know jargoon about data type change.Is typecast right? I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction	[reply]
Re^2: implicit data typecast by wazoox (Prior) on Jan 10, 2007 at 11:53 UTC
Perl actually does warn you : `use warnings; print "ho" if " 3 4 ">1; Argument "" 3 4 " isn't numeric in numeric gt (>) at - line 1.` [download] But if the string contains only leading or trailing spaces these are ignored.	[reply] [d/l]
Re^2: implicit data typecast by ww (Archbishop) on Jan 10, 2007 at 14:12 UTC
Updated on the suspicion that some (mis)read the previous wording as "snarky" when the question is merely intended to offer a parallel case to consider: ~~And if~~ If you lived in a locale where the language was not your native tongue, ~~you'd~~ would you complain about how it differed from the language of your childhood? In any case, you'll find a full and complete explanation of the output from your OP by reading about `eq` and `==` which do NOT perform the same test. Update, repeating Annonymonk's above: `eq` is used when testing for string equality; `==`, for numeric equality. Also as noted above, `warn` will let you know if you abuse `==`. But the bottom line is, I think, that (in the best of all possible worlds) different languages can serve different needs and can, therefore, be expected to call upon the programmer to use approprikate methods for each. Or, as others have suggested, your work (and your life) will be made easier if you understand your tools before attempting to use them	[reply]