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.
[download]

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 . . .

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.

---

My wife's blog

I think that if we increased the types to the resolution of O'Caml or Haskell (or even C/Java), it wouldn't really be Perl anymore. For this reason, I don't really advocate that Perl's type system be modified too much beyond its current state.

What I do advocate is that type safety is a Good Thing(tm), doesn't get in your way when implemented well, and we need a language that can take the idea out of acadamia and into the real world (like what Java did for VMs).

"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.