|
Re^2: Static typing is mostly a waste of time
by itub (Priest) on Apr 12, 2005 at 14:19 UTC
|
sqrt("four") eq "two"
Seriously, it's a question of being willing to pay the price of validating the input yourself. In many cases you have to do it anyway; for example, for square roots even if you can trust the compiler that you are getting a number, you have to make sure that it is not negative (unless your sqrt function deals with complex numbers). | [reply]
[d/l] |
|
|
Type systems don't concern themselves with what data you can put into the variable. They concern themselves with what you're allowed to do with that variable. Mathmatically, it makes no sense to take the square root of a string, or call an insert() method on an object that only runs selects, or give a background the color of laptop.
The holy grail is a program that is proven correct just by the fact that you compiled it without errors. Good, strong type systems are a major step in that direction. I'm not sure we'll ever actually reach that point, but it's good to try.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply]
[d/l] |
|
|
Or unless you have a type "Non-negative number".
| [reply] |
|
|
my subtype NonNegativeNumber of Num where { not $^a < 0 };
my NonNegativeNumber $x = 3; # works
my NonNegativeNumber $y = -3; # dies
Another example of using subtypes:
my subtype HTTP::Request::Method of Str where {
$^method eq any <GET POST HEAD ...>;
};
method send_using(HTTP::Request::Method $method) {
...;
# Note: You don't have to manually check for $method
# not being a valid HTTP method :).
}
--Ingo | [reply]
[d/l]
[select] |
|
|
...for square roots even if you can trust the compiler that you are getting a number, you have to make sure that it is not negative (unless your sqrt function deals with complex numbers).
Even if your sqrt doesn't do complex numbers, you'll still get an exception for negative answers. Which seems like a better alternative than returning a garbage answer.
$a = ["abc",123];
$b = -1;
print sqrt($a);
print sqrt($b);
| [reply]
[d/l]
[select] |
|
|
Actually, sqrt("four") eq "0". Try it if you don't believe me! :-)
| [reply]
[d/l] |
Re^2: Static typing is mostly a waste of time
by dragonchild (Archbishop) on Apr 12, 2005 at 13:50 UTC
|
You're arguing that Perl has a latent type system. I would argue that it has polymorphic built-ins. Are we in violent agreement?
| [reply] |
|
|
From what I saw of your arguments in this thread, you focus more on container types (scalar/list), whereas I'm focusing on value types (numbers/strings/etc.). Perl isn't latently typed for its container types--it has some very strong and static rules for what you're allowed to do with a scalar and a list:
perl -e '$foo = 1; push $foo, 2'
Type of arg 1 to push must be array (not scalar dereference) at -e lin
+e 1, at EOF
Execution of -e aborted due to compilation errors.
I'm arguing that value types are latent in Perl, and this isn't a good thing considering the advances in type systems over the last 30 years.
Then again, mathmatics has a whole branch dedicated to finding the square roots of negative numbers, which would be impossible without a similar hack . . .
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply]
[d/l] |
|
|
I'm arguing that value types are latent in Perl, and this isn't a good thing considering the advances in type systems over the last 30 years.
I've been thinking over my response all of yesterday. What I understand you saying is that Perl's SCALAR type is too broad. To me, this implies that you want to have the optional capability of having a numeric, a string, and a reference type. The argument I hear you and others making is that different operations behave in different ways, depending on the value contained in the SCALAR, thus they should be different types. Then, to maintain compatibility with the best parts of Perl's SCALAR type, all the operators and builtins that we would like to behave agnostically with reference to numerics and strings will be polymorphic. (References, I agree, should be separate from scalars.) And, you want this type-checking to happen at compile-time.
That's a very interesting argument. I'd have to see more details before I can agree or disagree. I like the basic premise, but the devil's in the details.
| [reply] |
|
|
sqrt string?
by Anonymous Monk on Apr 12, 2005 at 15:17 UTC
|
In that case, can you tell me what the square root of a string is?
Not a string, but this is one of my personal favorites...
print sqrt([42,"abc"]);
| [reply]
[d/l] |
|
|
Interesting. It seems to be taking the square root of MAXINT (2**32 on my platform), with some floating-point storage error in the answer.
While lacking strong typing might be detrimental in practical programs, it sure is fun to play with sometimes :)
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
|
|
You sure its not taking the sqrt of the memory address of the array?
$a = $b = ["abc",123];
print "\$a is $a\n";
$a =~ s/\D+//;
print "The decimal value of the address of the array is ",hex($a);
print "\n";
print sqrt(hex($a)),"==", sqrt($b),"\n";
| [reply]
[d/l] |
|
|