My view of what 'strongly typed' means

September 7, 2007

I was recently reading this slide from a presentation, which set me to thinking about the whole issue of what makes me consider something to be 'strongly typed'.

In high-level languages, I have a pragmatic definition: if 2 + "3" succeeds, especially if it is 5, your language is weakly typed. Thus, awk and Perl are weakly typed but Python and Ruby are strongly typed.

(I have to restrict this to high-level languages because this works in C, although it does not give you 5. If you are lucky this particular case gives you a core dump.)

More generally, I tend to think of strong typing as having two attributes: type conversions among core types must be explicit, and they are not guaranteed to be possible (they can fail for some types or some values). Things like 2 + 3.5 are excused because I tend to lump all forms of numbers together in my mind as one big abstract Numbers type; it's acceptable for the language to implicitly convert back and forth among the subtypes.

(I have to restrict this to 'core types' because languages generally give user-written types some hooks to do automatic conversions, so in a nominally strongly typed language you can create what are effectively weakly typed types, things that will automatically 'convert' themselves to other types without any warnings.)

By contrast, weakly typed languages either perform implicit conversions or allow you to ultimately force a conversion to happen, and sometimes both. Perl does the former; C does the latter.

I suspect that this implies that strongly typed languages need either static typing or an exception system, since they must either prevent invalid conversions from ever being possible or have some way to signal a runtime error when one is attempted.


Comments on this page:

From 194.8.197.204 at 2007-09-08 12:10:31:

What do you think should "2" + "3" do?

Aristotle Pagaltzis

By cks at 2007-09-08 14:31:48:

I'm willing to have "2" + "3" either be an error or result in "23". I think I would be alarmed if it was "5".

(I don't think that a strongly typed language has to restrict + et al to only operating on Numbers.)

From 194.8.197.205 at 2007-09-08 18:57:09:

Well, in Perl it’s 5, not "5". I agree that the latter would be perverse (or Tcl, I suppose). You probably find the former equally alarming, though.

In any case, you preference means that a + b will do different things depending on the types of the parameters. I like that in Perl, $a + $b means just one thing (and if I want the other, I can explicitly ask for it by saying $a . $b).

Btw, Perl provides no way whatsoever to coerce an array into a hash, or a scalar into an array, or whatever – neither implicitly or explicitly. You can’t even think anything like that. Is Perl then weakly typed?

Aristotle Pagaltzis

By cks at 2007-09-08 23:54:33:

Yes, I consider that "2" + "3" being 5 is just as weakly typed as 2 + "3" being 5. (Can you easily tell the difference between a result of 5 and a result of "5" in Perl?)

I wouldn't object to a language that made a + b always be numeric addition, but if it wants to be strongly typed it needs to fail when handed strings. As it happens, both Python and Ruby opt to overload + into string concatenation, which may or may not be a mistake.

I think of Perl as weakly typed because of the 2 + "3" issue; that it will refuse to coerce some types doesn't change this. Other weakly typed languages such as awk also have areas where they will refuse to convert or coerce types.

(For me, this is sort of the boundary between untyped languages and weakly typed languages; a weakly typed language has enough value type awareness that it will refuse at least some things.)

From 194.8.197.204 at 2007-09-09 10:39:40:

Well, why is 0 + 0.0 exempt from that rule?

Right, because they’re both of an abstract Number type, so conversion is OK.

Well, Perl just extends this to make Numbers and Strings instances of an abstract Scalar type, within which conversion is equally OK. And no, it is not practically possible to tell 5 from "5" in Perl. There are some ways in which you can, but they rely on leaky abstractions and don’t actually tell you anything useful. It goes so far that you can’t even tell when you’re under the hood, hacking around the guts using C. Strings and Numbers really are the same abstract type in Perl.

You could, of course, say that a language which makes String and Number types equivalent is weakly typed because of that, regardless of how its type system actually works. And that has, of course, very little to do with type systems. It’s just a question of how the types in the language were chosen, not how its type system works.

Personally I find any attempts to categorise languages along a strong/weak typing divide quite useless indeed. I find it much more interesting whether typing is early bound or late bound (does it cause compile time errors or runtime exceptions?) and whether it is possible to evade the type checker. (Even then, these criteria aren’t binary.) Java f.ex. turns out to be the very weird (and not very well-designed) beast it is, all the “dynamic languages” end up next to each other, and you can easily find the true “strongly typed” languages such as Haskell and the ML family forming a clique of their own.

Aristotle Pagaltzis

By cks at 2007-09-09 11:04:51:

To me the difference is that while the different forms of Numbers are in some sense all an implementation detail, the same is not true of Strings versus Numbers.

This is even true in a pragmatic sense: consider 1 + "abc". Unlike something like 1 + 2.5 this has no natural resulting value. You can give it a value, but it has that value only through language convention.

From 65.172.155.230 at 2007-09-10 13:16:48:

This is even true in a pragmatic sense: consider 1 + "abc". Unlike something like 1 + 2.5 this has no natural resulting value.

Ok, consider something like: 1 + 2 * 1000 * 1000 * 1000 * 1000 * 1000 as against: 1 + 2. * 1000 * 1000 * 1000 * 1000 * 1000 ... oops, completely different (and "unnatural" to someone who doesn't understand what happened and why) results due to a one character difference and the resulting type conversions.

But maybe I'm biased in that I learned Perl before Python, and having to explicitly convert strings and numbers all the time in print statements made me want to hurt people even more than the invisible syntax.

By cks at 2007-10-22 23:32:26:

Department of belated replies: I'm surprised you had problems in print statements, because print statements are one of the places that Python does a lot of automatic converting of things to strings.

(It happens both in print and in the % string formatting operator for %s fields. Strings don't automatically convert to numbers for %d, though.)

From 128.33.22.52 at 2009-07-09 17:58:27:

Even more belated, but I suspect that the printing problem 65.172.155.230 had came from statements like:

 print "The number you requested was: " + the_number

or

 print "You would need " + num_liters + "L of water to fill the container."

These statements need explicit conversion. Of course you can, and would generally be encouraged to, write:

 print "The number you requested was:", the_number

and

 print "You would need %sL of water to fill the container" % num_liters

but if someone were new to python they wouldn't know that.

 -- Jeff Kaufman
Written on 07 September 2007.
« When you don't want RAID-5
Weekly spam summary on September 8th, 2007 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 7 23:49:17 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.