strict Haskell dialect

[Ben Rudiak-Gould]

Wolfgang Jeltsch wrote:
> Since laziness often allows you to solve problems so elegantly, I'm really 
> scared of the idea of a "Strict Haskell"! :-(  Is laziness really so "unreal" 
> that real-world programmers have to see it as an enemy which they have to 
> fight against?

Non-strictness gives you some useful guarantees about program behavior, but 
strictness also gives you useful guarantees. Strict datatypes are 
inductively defined (at least in SML), which means that you can prove useful 
properties of functions defined inductively over them. Consider length :: 
[a] -> Int. In SML you can prove that this terminates and returns an Int for 
any list. In Haskell, you can't prove anything about this function. It might 
return an Int after unboundedly many reductions, or it might diverge, or it 
might throw any exception whatsoever. In my experience exceptions are less 
useful in Haskell than in other languages for this reason. The dynamic 
execution stack that's used for exception handling isn't apparent from the 
static structure of the code. Exception specifications in the style of Java 
or C++ simply couldn't be made to work in Haskell.

All of the above applies only to non-strict data, though. I don't know of 
any theoretical disadvantages of non-strict let/where binding, just the 
usual practical problems (constant factors in the time complexity and tricky 
space complexity).

Personally I'd like to see Haskell become "the world's finest strict 
language" just as it's already "the world's finest imperative language". I 
think I know how to mix strictness and nonstrictness at the implementation 
level [1], but I don't know how best to expose it in Haskell.

-- Ben

[1] http://research.microsoft.com/Users/simonpj/papers/not-not-ml/index.htm