Lambda the Ultimate

In general, there is no static link between the name of a file and the type of its contents. Thus, types of the parts of a program that perform file I/O can only be checked at run­time, when reading or writing. Therefore a certain amount of dynamic typing is unavoidable.
But we do not want our entire language to become dynamically typed...

Not merely, but mostly. It is also because most DTL users don't understand that DT languages can be embedded in ST languages, and because they think they DT programs are simpler than ST programs, when in fact it is just that fewer of the complexities are made explicit.

Is the current mainstream of statically typed languages giving static typing a bad name?

Yes.

Is a language without an Obj.magic or unsafePerformIO doomed to obscurity?

I don't think those two have much to do with DT vs. ST. They both allow untrapped errors to occur, whereas "DTL" is usually interpreted to mean a language which traps all errors. I imagine many DTLs also have an equivalent of Obj.magic, for example the ability to compile with an -unsafe flag or something.

Sure, you can do this embedding, but the result will be extremely painful to program in, so I can't say I'm swayed by this argument. I was a big ocaml advocate until I found that the first serious program I wanted to use ocaml for couldn't be done in a reasonable way because of ocaml's object system's lack of downcasting (even safe downcasting as in java). The notion that a ClassCastException could be thrown at runtime is apparently so abhorrent to the ocaml developers that they're willing to keep their object system weak in order to make this impossible. But that means there is no reasonable way to simulate double dispatch (which is what I wanted). Newer static languages like Nice address this issue, so we'll see. I like static languages but I can appreciate the DT advocates when they say that there will always be some interesting kinds of programs that ST languages won't be able to handle (without simulating a DT language, that is).

I think you're overstating the case. First, with a macro system, there is zero overhead. Even without a macro system, it's not much of a burden; there is some boilerplate, but it only needs to be written once.

infixl 9 #
 
data O = Int Integer | Fun (O -> O)
 
(#) :: O -> O -> O
(Fun f) # x = f x
_ # _ = error "tried to apply non-function"
 
identity = Fun (\x -> x)
two = identity # Int 2
 
instance Eq O where ...
instance Ord O where ...
instance Enum O where ...
instance Num O where
  (Int m) + (Int n) = Int (m+n)
  _ + _ = error "tried to add non-integers"
  ...
 
seven = Int 3 + Int 4

What was so painful about that? The Fun which you need to prefix abstractions by is usually a keyword in ML-like languages, so it's certainly tolerable. And the fact that you have to write "#" for applications is arguably no worse than having to write parentheses around arguments in Algol-like languages.

And with a macro system, both these issues disappear, along with the need for the Int coercion. Furthermore, you can extend the language semantics in more-or-less arbitrary ways without having to fiddle with a compiler's source code. You could make the O type monadic, for example, and easily add state, continuations, and so on, or add new primitive datatypes, function memoization, OO features, whatever your heart desires, and I bet it will run faster than most simple DT implementations as well.

The notion that a ClassCastException could be thrown at runtime is apparently so abhorrent to the ocaml developers that they're willing to keep their object system weak in order to make this impossible.

Maybe that's the real problem. Once you've tasted of the forbidden fruit...

I'm not saying that there aren't problems with Ocaml's object system, or even that throwing an exception in this case is unreasonable, but I understand the reluctance to accept easy solutions if they don't fit the spirit of the language.

I like static languages but I can appreciate the DT advocates when they say that there will always be some interesting kinds of programs that ST languages won't be able to handle

There will always be some "interesting" kinds of programs that ST languages can't handle, true, but in practice 99% of what you code does not involve such programs, and when it does the ST analogue often has advantages over the unsafe version.

(without simulating a DT language, that is)

I think of it the other way around: DT languages are simulating ST languages. They do strictly less for the programmer, and ST programs carry more information. (A simulation of X is generally only an approximation of X; it carries less info.)

import Prelude hiding ((.))
 
(.) :: O -> O -> O
x . (Fun f) = x f

If yuo are trying to do this, Chris Rathman's title indexes will come in handy.