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

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).

Try treating a hash like a scalar. Or a scalar ref like an array ref.

Perl is strongly typed.

You are confusing the type associated with the name of a variable with the type associated with its value. In C, you declare a type for the name of a variable, as in double i;, but the content of i can be anything. The language just won't let you assign from a variable with name declared to be of one type to a variable with a name declared to be of another. It doesn't actually know what the variables contain, however.

In Perl, that's different. The language always knows the type of the content of each variable.

Makeshifts last the longest.