I still think Dominus said it best (quoted below). And I appreciate the research he did into this question.

Message-ID: <20010623153305.20460.qmail@plover.com>
To: clpm@lists.eyrie.org
Subject: Re: Perl *is* strongly typed (was Re: Perl description) 
Date: Sat, 23 Jun 2001 11:33:05 -0400
From: Mark-Jason Dominus <mjd@plover.com>
Newsgroups: comp.lang.perl.moderated

. . .
...a type system that only has three or four types in it was a very weak type system indeed. Fortran IV (1966) has more types than that, and I don't think many people would claim that Fortran was a strongly typed language; my previous message showed that AWK has similar checks, and I have never known anyone to make the claim that AWK is a strongly typed language.

My argument wasn't that Perl isn't strongly typed, because I don't pretend to know what that means. Let me say that again: I don't know what it means for a language to be 'strongly typed'. I'm not arguing with you because I think you're wrong and I think Perl is not a strongly typed language. I do not know what 'strongly typed language' means. (I did some research, and it didn't help; see below.)

All I said was that if Perl is considered strongly typed, then I don't think the concept is useful or meaningful, because *every* language is strongly typed. It appears from your argument above that you would consider AWK and Fortran IV to be strongly typed languages also. That may be a logically consistent position to take, but it does not seem to be a very useful one. My original message asked Randal to produce an example of a language that is *not* strongly typed, and I don't think you can do that---if you're going to rule out examples like AWK, that doesn't leave you with very much to work with. (I guess you could bring up assembly language. But that would be a silly evasion.)

From a brief survey of web documents about strong typing, it appears that the description 'strongly typed language' does *not* have any useful or agreed-upon meaning. The confusion is not simply about where to draw a line on a linear scale of type granularity or degree of error checking or anything like that; it's not that some people think a strongly-typed language needs fifty types and others think it needs only thirty. There appears to be a fundamental confusion about the basic meaning of the term 'strongly typed language'. In a couple of hours, I found eight different and incompatible definitions of 'strongly typed language':

1. A language is strongly typed if type annotations are associated with variable names, rather than with values. If types are attached to values, it is weakly typed.


2. A language is strongly typed if it has compile-time checks for type constraint violations. If checking is deferred to run time, it is weakly typed.


3. A language is strongly typed if it has compile- or run-time checks for type constraint violations. If no checking is done, it is weakly typed.


4. A language is strongly typed if conversions between different types are forbidden. If such conversions are allowed, it is weakly typed.


5. A language is strongly typed if conversions between different types must be indicated explicitly. If implicit conversions are performed, it is weakly typed.


6. A language is strongly typed if there is no language-level way to disable or evade the type system. If there are casts or other type-evasive mechansisms, it is weakly typed.


7. A language is strongly typed if it has a complex, fine-grained type system with compound types. If it has only a few types, or only scalar types, it is weakly typed.


8. A language is strongly typed if the type of its data objects is fixed and does not vary over the lifetime of the object. If the type of a datum can change, the language is weakly typed.

Some of these are contradictory; some are merely orthogonal. Many came from class notes for undergraduate CS courses. Not all of these instructors and experts can be mistaken. The only sensible conclusion is that there is no agreement about what it means to be a strongly typed language.

Examples are no help here:

I found several pages that asserted that C is a strongly-typed language.
I found several pages that asserted that C is a weakly-typed language.

I found several pages that asserted that C++ is a strongly-typed language.
I found several pages that asserted that C++ is a weakly-typed language.

I found several pages that asserted that Lisp is a strongly-typed language.
I found several pages that asserted that Lisp is a weakly-typed language.

I found several pages that asserted that Perl is a strongly-typed language.
I found several pages that asserted that Perl is a weakly-typed language.

. . .

original message by MJD ⇒(Google groups)

I thought Perl 5 was Strongly Typed. In what way is it Weakly Typed?

On the other hand, if you consider the different kinds of scalar datatypes -- boolean, string, int, float, reference -- it is weakly typed. These types of values can all be freely coerced into each other, with the exception of coercing into a reference. You can freely perform int-specific or string-specific operations on any scalar variable.

But you can never use hash-specific operations on an array, or vice-versa.

*shrug* Some things are legal, some are not: it depends on whether the compiler autodetects the type, and issues a warning, or autodetects the type, and comes up with a conversion or a default value, or the function does something different when called with different data types.

keys(@x) is illegal. But length(@x) is legal, if largely pointless, as is length(%x). delete($x10) is a very different operation, under the hood, than delete($x{10}), but both work fine.

You can freely perform int-specific or string-specific operations on any scalar variable.

There's an implict scalar representation for both arrays and hashes, so you can freely perform integer or string specific operations on arrays and hashes, too.

$x = @x+15 is legal Perl. So is "$x = %x + 5" (althought it will issue warnings).

--
Ytrew

I don't find strong typing to be a very useful concept in dynamic lanaguages. I'm not even sure it makes sense to talk about strong typing. Types are determined by the interpreter at run time. The type of a piece of data is carried along with the data so there is only 1 possible way for the interpreter to treat it - it must treat it the way that type should be treated.

The only way to break this is to allow programs to pick a pointer into arbirary memory and have the interpreter use it as a value, a feature so dangerous (and almost certainly not what you want to do) that none of the dynamic languages I know allow it (except at the interface to C, e.g. perl's XS system).

So perl and other dynamic languages are strongly typed but it's not like someone sat down and said "I'm going to make my language strongly typed", it's because a weakly typed dynamic language doesn't really make much sense.

Reach in arbitrary memory? Sure. We can do that. :-)

unpack 'P', pack 'j', []

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

I've never seen p and P in pack before and I can't figure out what they actually do (as in I have read the docs, tried some code but still don't understand). I thought

#! /usr/bin/perl -l

$a="fergal";
$p=\$a+0;
print $p;
$x=unpack("P9", pack 'j', $p);
print length($x);
[download]

might read the first 9 bytes of the SV structure for $a but it just has length 0. Do you have a demo?

Anyway, this is not really what I'm getting at. You can't use this to try treat the memory for a perl array variable as a perl string variable, at most this allows you to treat the memory for a perl array variable as the C string inside a perl string variable.

Imagine you could twiddle the pointer inside a perl reference value, it still wouldn't be weakly typed. If you point the ref at a bit of memory that contains a perl string variable then it will become a string-ref if you point it at an array variable it will become an array-ref (I think this is the case although I'm not an XS whizz and I don't have time to test it as I'm going on holidays in an hour!). So for perl to be weakly typed I would have to wrong and the language would have to have this reference twiddling feature built in.

I remember Audrey Tang mentioning that the Perl 6 type system has been influenced by the Dylan programming language, in which "Programs can be written on a continuum from fully dynamically typed to fully statically typed". So I guess Dylan could also be classified as "hybridly typed". When you stated that Perl 6 is the only language classifed as hybridly typed, I assume you are referring to this link: wikipedia Type System (next time, please provide the link you are referring to). Though this link classifies Lisp as dynamically typed, it does not explicitly mention the (Lisp-derived) Dylan.

(Common) Lisp also supports type declarations that may be used by the compiler to generate optimized code.

I had always though that Perl6 is comming so close to Common Lisp that instead of writting a virtual machine like Parrot and a Perl6 to Parrot compiler, it would be much easier to write a Perl6 to Common Lisp translator and run it on top of a free Lisp environment like CMUCL.

There was actually some talk of a CL backend for Perl 6, especially given the CLOS-like direction the metamodel has taken. However, CL's type declarations are mostly just hints for the compiler, and (as the spec says) the behavior is largely undefined when a value that does not match the type is assigned to a variable with an attached type declaration. In effect (from what I can deduce) this means there is no actual type "checking" in CL.

But regardless of this, since everything in Perl 6 will be an object, we basically thought of building it on top of CLOS. But alas, LISP has long suffered from several competing incomplete implementations and we could not find one with good enough (and fast enough) CLOS support to do this.

-stvn

- Perl 6 was the only language classified as Hybridly Typed when it comes to Staticness.

I'm guessing that's refering to the fact that while Perl 6 will be staticly typed by default, the ability to define your own grammer on the fly takes away any garuntee of what a particular variables type is.

On-the-fly grammer redefintion should not affect the actual way in which the type system works. It might play some tricks on the programmer so that a Str type annotation is turned into a Num type annotation, but while that would be kind of silly, it would not affect the way the underlying type system works.

Actually, Perl 6 will try it's best to be as statically typed as possible, including performing some type inference when there are no programmer written type annotations present. Anything which it cannot figure out during the compile phase, it will leave until runtime (which is fairly common in other "staticly typed" languages like Java, etc.). This combination of compile time static type analysis and runtime type constraint checks is sometimes referred to as a hybrid type system, but once again it is not unique to Perl 6 by any means.

However, this may or may not be what they mean. Perl 6 will also combine a nominal type system (types are compared by names) and a structural type system (types are compared by their defined structure). This could be seen as a hybrid type system too, however this too is not unique to Perl 6 either.

So possibly they mean that Perl 6 is unique becuase it's type system is; as static as it can be and as dynamic as it needs to be, will check types by name if it can or by structure if it needs to, and in the end is entirely optional.

-stvn

• (Completely OT) - Hero(i)n programming language on Slashdot
• Static typing is mostly a waste of time
• Griping about Typing

"I thought Perl 5 was Strongly Typed. In what way is it Weakly Typed?"

Ha? How so? when the language even does not differentiate string and number that much.

That just means it doesn't distinguish between types you feel are important. Strong vs. Weak typing has to do with how easy it is to coerce various types into one another. There are very specific types in Perl.
• Scalar
• Hash
• Array
• Subroutine
• Glob
• Format

While you may be able to extract a scalar from an array and an array has a meaning within scalar context, that doesn't mean you can coerce the array into the scalar. Try doing any sort of meaningful work converting between formats and subroutines.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

there is a hole:

use Devel::Peek;
$foo = *foo;
Dump($foo);
[download]

I realize now that there is clearly no standard definition of "strongly typed".

For me it related to type casting pointers.

In "Weakly Typed" C/C++...

Foo f;
Foo *pf = &f;
Bar *pb = (Bar*) pf;
Bar& b = *pf;
[download]

Here, f points to a piece of memory it will treat as if it was in the structure of a Foo. b points to *the same* piece of memory and instead it will treat as if it was in the structure of a Bar. Foo and Bar may have totally unrelated structures. This is what I was thinking of in terms of weak typing.

I thought you couldn't do that in Perl - hence I called in strongly typed.

(It looks like you might be able to something similiar with the pack/unpack magic mentioned above - although it is certainly not a common practice.)

-Andrew.

My favorite take...

So what is "strong typing"? This appears to be a meaningless phrase, and people often use it in a non- sensical fashion. To some it seems to mean "The language has a type checker". To others it means "The language is sound" (that is, the type checker and run-time system are related). To most, it seems to just mean, "A language like Pascal, C or Java, related in a way I can't quite make precise". If someone uses this phrase, be sure to ask them to define it for you. (For amusement, watch them squirm.)

As far as I've been able to determine, the only way to use the terms "strong", "weak", "static", and "dynamic" in relation to typing is something like this:

1. A language can be dynamically typed. Languages like Perl and Ruby fit this description.
2. A language can be statically typed. Languages like C and Haskell fit this description.
   1. A statically typed language can be strongly typed. Languages like Haskell fit this description.
   2. A statically typed language can be weakly typed. Languages like C fit this description.

I think that dynamic typing can be split into two subcategories as well — duck typing and . . . whatever the converse dynamic typing category would be called.

This raises a question, though. What do we do with a language like Objective C? It looks to me somewhat like it's both a duck typed language and a static, weakly typed language. Of course, I could just be wrong about the whole thing.