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.

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.

So, yes, Perl as a whole defies classification

Well at least we can agree on this. I like your breakdown, its a very interesting way of looking at it. However, I prefer to look at a language as having a single type system rather than several type systems layered upon one another. You (and chromatic and merlyn) say tomAto, and I will say tOmato. IMO, thats one of the things that makes perl so great, because there is TIMTOWTDI, there is also more than one way to look at it too.

That's why me or merlyn or chromatic will assert that Perl is strongly typed.

Funny, i find that sometimes I don't always agree with them either ;-)

-stvn

It's interesting to compare tha various definitions of both what "strongly typed" means, and how Perl typing system is characterised by various people with the "industry standard definitions" of that term.

Personally, I find it a stretch to consider a language that has only one type (plus two conglomorates) as strongly typed. I find there to be very little difference between "one type" and "no types".

Assembler has no types--just memory and pointers to memory. Any pointer can point to memory containing anything. And any piece of memory (regardless of what it contains) can be treated as anything, including a pointer to anything.

Perl has only one type: Scalars, plus two conglorates: hashes of scalars and arrays of scalars. And a scalar be used to contain any type of data: characters, integers, reals, strings, and references to anything. Often it contains many of these simulataneously.

Whilst I can't fault your four levels of type definition, using the phrase "a strongly typed language" to describe Perl, given the industry accepted definition of that phrase, is something of a stretch.

Of course, I'm not necessarially agreeing with that particular definition entirely, and I totally disagree that (all) langauges traditionally defined as being "strongly typed" actually meet that definition. More to the point, even those that do meet that definition rarely, if ever, deliver the kinds of benefits that "management" have been led to expect of them, by such definitions.

Ultimately, I think that contextual typing is the most powerful (and maybe revolutionary) concept in perl. It won't really come to fruition until perl 6 hits the streets with it's enhanced contextual information, but it will be very interesting to see how things evolve once it does.

The very idea that I can be passed some entity and assign it to a local variable defined as some type and the entity itself (or rather the author of the entity) can decide to give me the appropriate representation of that entity to fit my requirements--or raise an exception if it doesn't know how to convert itself to my requirements is just so powerful.

Rather than me, the user of the entity trying to decide how to perform the conversion to the type I need, context moves that responsibility back to the author of the entity where it belongs.

I'm not yet sure that this idea will be taken to it's full potential even with Perl 6. If I try to assign a scalar given to me to a variable defined as  my int  $x; (on a 32-bit platform) and the scalar contains '5e10', what will P6 do? Will the enhance want function notice the discrepancy?

What if I try my Animal $beast = new Dog( ... );? I could see the possibility of want detecting the caller context as Animal and allowing the author of the Dog module to provide a return of the Animal instance (reference) that underlies the Dog instance regardless of whether Dog inherits from Animal or is composed from Animal and one or more other Classes. I guess you could do this now by providing a Dog::getAnimal method.

Perl already has this kind of context awarness to a certain level. If you use a reference in a scalar context, it gives you a textual representation of the reference. If you use [cpna://overload], you can tweak this to provide a more meaningful representation without the need to call an asString() method explicitly.

Finding uses for such an extension of the context information isn't at all hard. For example: A Dog in a Dog context might sort according to its bred, but in an Animal context it might sort according to it's genus (Is that the right term?).

And yes. I rambled. And no, I'm not critiquing your post. Just adding my rambling thoughts to the mix.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon