Try treating a hash like a scalar. Or a scalar ref like an array ref.

You can however treat a number like a string and a string like a number in many cases. And while the "public" type system my just call all these scalars, the underlying implementation makes a distinction (i think it is IV and SV types, i don't recall exactly).

And then there is of perl's idea of contexts. I can use an array like a scalar and get back its length. I can assign an array to a hash without too much trouble if the array has an even number of elements. This adds a level of flexibility (and sometimes confusion on the part of the programmer) to perl's type system which keeps me from seeing it as a truely strongly typed language. Yes, it's closer than some, but IMO its not that close. However just as TIMTOWTDI, there is more than one way to look at it too.

As I said, it is very difficult to classify a language as having a specific type system, most all will blur the lines and defy strict classification. One of the great things about perl IMO is its inability to be classified.

When I say "treat a hash like a foo", I mean interpreting the bytes in memory that make up a hash (or more generally, the internal representation of any hash) in a different way. That isn't possible in Perl.

There are defined and specified mechanisms for type conversions, and you can indeed convert any type to any other in some fashion, but you're always converting the values, never casting them.

In that sense, Perl is indeed strongly typed, whereas C is truly a glorified assembler.

Makeshifts last the longest.

When I say "treat a hash like a foo", I mean interpreting the bytes in memory that make up a hash (or more generally, the internal representation of any hash) in a different way. That isn't possible in Perl.

Very few langauges nowadays allow direct access to bytes of memory in that way. So I would not consider that in my evaluation of a type system, only the type abstraction which the language implements.

you're always converting the values, never casting them.

Yes, this is true, and the more I thought about it, the more I realized that I was not being specific enough. This is how I evaluate perl against the defintion I presented for a type system. First, perl's ability to define types is partially implemented by the sigils ($@%) and partially by syntax (\ for references). But IMO this is only partially complete, which I will explain later. As for the rules for types.

Type equivalence rules are laid out in perl, however, incorrect usage (comparing two types which are not really comparable) does not always produce a fatal error, sometimes only a warning, and without -w or use warnings, sometimes it does nothing. And because of the complexity of contexts and of automatic conversions, this can get quite complex and hide insidious bugs (especially for the less experienced).

While this might be considered strong typing to you, I feel that with all the complexity of contexts and automatic conversions, you loose some of what strong typing is good for. Which is to not allow you to perform an operation on a type for which the operation is not supported. If through these mechanisms all types support all operations, are you not perhaps defeating the puporse?

Type conversion is pretty well thought out and specified, but things like contexts adds a level of complexity to this which can correctly produce a result, even if it is not what the author intended. Throw overloading and tie into the mix, and you have a lot of ways in which you can "subvert" the type system. Again, at some point it might be strong typing, but very quickly you can weaken that typing without trying to hard. Just try to check reference value arguments in a subroutine. Is is a HASH, or is an tied HASH, or is it an object which you can treat as a HASH? Should I call UNIVERSAL::isa or trust that if an object has overloaded isa that have done it sanely? This gets very tricky very fast, IMO strong typing should not be tricky.

The last one Type Inference perl does an okay job of in most contexts, but where I see it failing is with objects. As has been discussed many times, objects were somewhat bolted onto perl and are maybe too open. The ability (as you pointed out in another post in this thread) to dynamically (and if you want to, arbitrarily) change a classes @ISA at runtime breaks anything strong about this part of the type system. The ability to dynamically add methods does too. I am left without the ability to determine much about my objects with any level of certainty until the very last moment before I use them.

But again, in the end, my point is that perl defies classification. To say it is strongly typed is IMO a simplification of the actual underlying complexities of perl's type system.

-stvn