Well, in my nomenclature — which isn’t universal, but whose is? — TCL is not a dynamically typed language, it is an untyped one like assembly languages, BCPL, BLISS.

Statically typed languages have types deduced by a static analysis.

Dynamically typed languages have a type attached to values.

Untyped one have only one kind of values (words for BCPL and BLISS, strings for TCL) and the type is deduced from the operation which is applied more or less blindly on the values.

Automatic conversion may blur the difference between dynamically typed languages and untyped one. Evolution may also give an untyped language some dynamically typed flavor (that’s perhaps the case for TCL — I’ve not used for too long –, it’s also the case for some shells which started as untyped and then acquired values which are of a different kind — arrays for instance) making their behavior inconsistent and difficult to explain.

Duck typing is another axis. It’s a way to check type conformance. It’s a variant of structural typing where only the used characteristics are checked. It can be used in statically typed languages (templates in C++ is duck typing); in dynamic languages the check may be delayed to use time.

No. Whether a language is statically or dynamically typed, or weakly or strongly typed, has nothing to do with interpretation/compilation, which is an orthogonal implementation detail.

Perhaps the best example to use here would be Hugs, The Haskell interpreter. For those unaware, Haskell is a very strongly typed language with a very powerful type system, and is somewhat of a poster child for strong type systems with solid mathematical backing.

Consider also a language such as Scala, which has a type system with similar power and is very difficult to place between compiled and interpreted. It “compiles” down to JVM Bytecode, which is then interpreted/compiled/JITted depending on various implementation details of the JVM it happens to be running on.