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.

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

You can't really try to successfully take all that into consideration on the same level. Rather, I would say that Perl has multiple distinct type systems layered on top of each other:

1. The base type system, the one actually concerned with the representation of values, is strongly typed and completely uncircumventable. You can neither cast nor convert values into each other at this level, in any way, shape, or form.
2. Context is a distinct typing system and quite strongly typed (think of "there is no list in scalar context", f.ex). However, it has a full set of conversion rules covering all axes, so in practive, that hardly matters.
3. The high level type system, the level at which strings and numbers differ f.ex, is just about typeless. This layer is vague and always implicit, never declared, nowhere to be enforced.
4. Finally, the type of an object is yet another fully disjoint typing system; in fact it is just metadata dangling off of a thing, only accessible via a reference. I am not sure how strongly typed this can be considered to be, but even if so that is ultimately meaningless since it is completely dynamic to the point that what it means that an object is of some type can completely change at any point. It also exists in a kind of vacuum, because the only time it ever matters is on method lookup. In all other circumstances it is completely inconsequential.

If we tally up, we find that we have two explicit typing systems which are both strong, and one which is barely definable and can hardly be called a typing system at all. Then we have another one dangling on the side of it all, nearly completely isolated and so ridiculously dynamic it doesn't even make sense to talk about whether it is strong or not.

So, yes, Perl as a whole defies classification.

If you scale back and look at the innate typing that's an explicit part of the language, however, you find that to be a strong one. That's why me or merlyn or chromatic will assert that Perl is strongly typed. Of course, noone will dispute that it is a strange example of strong typing. :-)

Makeshifts last the longest.