Q:

What is the relationship between static typing and lazy functional languages?

I'm curious about the relationship between static typing and lazy functional languages. Is it possible to have a dynamic lazy functional language, for instance? It seems as if all of the lazy functional languages out there are statically typed (Haskell, Miranda, etc), and all of the dynamic functional languages use strict evaluation (Clojure, Scheme, etc).
In particular, the Wikipedia article on Lazy evaluation reads:

However, with lazy evaluation, it is difficult to combine with
  imperative features such as exception handling and input/output,
  because the order of operations becomes indeterminate. Lazy evaluation
  can introduce space leaks.

What is the role that static typing plays in preventing space leaks?

A:

I don't believe that static types play a role at all. For example, consider the untyped lazy language, Lazy Racket. I haven't heard any indication that it leaks space in a way that Haskell (for example) does not.
Side effects, on the other hand, are a problem because humans find the order of evaluation of strict evaluation to be (relatively) natural, and call-by-need is much harder to mentally predict.

A:

What is the role that static typing plays in preventing space leaks?

Types can be used to track the lifetime of objects, statically ensuring the absence of leaks.
An example would be region types and other effect types.

A:

Lazy evaluation and static typing are independent concepts.

Untyped

Lazy evaluation The untyped lambda calculus with normal order reduction strategy (or call by need). Always the leftmost redex is evaluated first.
Eager (strict) evaluation The untype lambda calculus with applicative order reduction strategy.  Lambda terms are always reduced before they're substituted to other terms.

Typed

Lazy evaluation Haskell is an example.
Eager evaluation OCaml is an example.

Roughly speaking, evaluation is something that happens when the program is run.
Typing is something that happens when the program is compiled.
But of course there is an important correspondence between a typing system and an evaluation strategy:

If a term M reduces to N and M:σ (M is of type σ) then N:σ.

This means that when we run a program that has some type σ then the value
will have the same type. Without this property, a typing system is really
useless (at least for programming). This also means that once we have typed a
program during compilation, we don't need to remember the typing information
when evaluating it, because we know that the result will have the correct type.

Concerning the Wikipedia article you're quoting. There are two different things:

Imperative features. This isn't really related to a typing system. The problem is that if evaluating certain expressions has side effects (like I/O in most languages) in lazy settings it's very hard to predict when (if at all) a side effect occurs. Therefore once you have lazy evaluation, it's hardly possible to have an impure language.
One exception to this is the Clean language. It uses a special type system to handle side effects in a lazy setting. So here there is some connection between the evaluation strategy and the typing system through handling side effects: The type system allows handling side effects in such a way that we can keep lazy evaluation.
Space leaks. This is a known drawback of lazy evaluation. See Building up unevaluated expressions or Ch. 25 Profiling and optimization in Real World Haskell. But again this has nothing to do with type systems - you'd get the same behavior in an untyped language.

