Incidentally I thought that type inference in Standard ML was a form of strong typing, but I don't know Standard ML. Since you appear to think otherwise, how would you describe the distinction that you'd draw?

It all depends upon what you see as strong typing, maybe static typing is a better word for it. It is more specific.

My first experience with strong typeing was with Ada, which is probably one of the most draconian type systems out there. Which IMO is a good thing since Ada was intended to be used in things like missle guidance systems and is mostly used today in Aerospace (I think Boeing still uses Ada).

With Ada (and similar "staticaly" typed languages), you must strictly define your type and the scope of any polymorphism is limited. For a more common example, think of Java, there is no universally polymorphic type so the primatives like the int, string and array types are never compatible with others. If you want to be overly permissive with your types in a method argument, you declare the them of type Object. But before you really do anything with them you need to cast them to the proper type.

ML is not statically typed, you dont have to define it to use it, nor do you have to cast it when you do intend to use it. In your function arguments, you can either not define your type, or you can just define your type as 'a, which is sort of the universal polymorphic type. ML will figure it out for you (at compile time too) and give you the protection of type-safety. Dominus actually has a really good article which talks about this (start at slide 14), and does a much better job of explaining it than I really can.

I guess because typing is somewhat optional in ML, I don't view it as strong typing really. Again, maybe static is the better word for it.

... but I don't know Standard ML

You should give it a try, I actually think you in particular might like it. It may not be as practical as perl, but I think it is one of those languages which just the act of learning it can give you a lot of insight.

I guess because typing is somewhat optional in ML, I don't view it as strong typing really. Again, maybe static is the better word for it.

I think you'll probably confuse a fair number of people :-) I've seen a number of definitions of strong/weak typing but ML would always come in on the strong side. The most common definitions I find are:

• Strong: The language knows what type something is (ML, Perl, etc.)
• Weak: You have to figure out what type something is (C, assembler, etc.)
• Static: We know what type something is at compile time (ML Eiffel, etc.)
• Dynamic: We know what type something is at run time (Perl, Ruby, etc.)

These certainly aren't universal (what I call "dynamic" above are often called "weak" too), but ML would always fall into the "strong" category.

The difference you're talking about (where the language figures out the type of something at compile time without you having to tell it all the time) I've seen called "inferred typing", which seems suitably descriptive.

I think you'll probably confuse a fair number of people

You are right, my defintions are both ambigious and not quite right. That said, the definitions you provide are overly simplistic, and in places debatable. So lets get down to specifics.

I see a type-system as being composed of 2 parts. The first part is a set of rules for defining types within a language. The second part is how those types interact, which can be broken down into; type equivalence, type compatability (which includes rules for type conversion and casting) and type inference (rules for figuring out types).

When I said I did not think of ML as staticaly typed, I was mistakenly only including the first part. ML's types are optionally statically defined, however the end result of ML's compilation process is a static type determination. In the end, my defintion of ML as not being staticly typed is wrong. However, ML (and similar lanaguges like Haskell) is not that easily classified.

Your defintion of a strongly typed language is simplistic.

The language knows what type something is.

A strongly typed langauge is usually considered to be a language in which (through the langauge implementation) the rules of the type use can be enforced. Meaning that it can ensure that only those operations which are supported by a certain type can be applied to that type. It is not enough to just know it, you must be able to enforce it. By my defintion, perl is not really a strongly typed language. While it does know much about the types, it does not always enforce the rules of that type (sometimes only warning the programmer).

Your defintion of weakly typed langauges is also not quite clear.

You have to figure out what type something is (C, assembler, etc.)

The fact is that there are no types in assembly langauges at all (at least not any I am familiar with, which truthfully is not that many). C is on the other hand has the first part of a type system (means of defining a type) and most implementations will enforce the rules of the second part at compile time (one of the reasons C is so fast is that it has very little (if any) run-time checking in most implementations). C does have several loopholes in its type system though which allow the rules to be broken or bent (union types are one example). So while C's type system is not perfect and might be viewed by some as weakly implemented, I don't know if I would really call it weakly typed. I certainly would not group it with the type-less assembler.

I would be hesitant to define weakly typed lanagues, since most all languages have some notion of types, and do some checking to enforce their usage. I would think that it is best to just look at the degrees of strength of a type system, rather than just define it as weak, but I might be just splitting sematic hairs here.

Your defintion of static is also little unclear.

We know what type something is at compile time

A staticly typed langauge is usually thought of as a strongly typed language in which types can be checked at compile time. What your defintion above does not say is the strongly typed part. This is important because it is not enought to just know something if you don't have the means to do anything about it. Very few languages are purely staticly typed, even Ada will leave some things to be checked at run-time.

Your defintion of dynamic is also unclear and not complete.

We know what type something is at run time

Sometimes a dynamicly typed language will not know what type something is at all and assume the programmer is doing the right thing (this is true of some situations in some implementations of LISP and Scheme), and some lanaguges usually considered statically typed (like Ada and Pascal) will defer some checks till run-time. Dynamic binding is also usually associated with late-binding languages like Smalltalk in which a variable is essentially a pointer and its actual type association is put off till the last minute.

The problem I think in defining typing too much is that very few languages will ever fit easily into your defintions. Most langauges will blur the edges and cross a few lines.

-stvn