strict Haskell dialect
Benjamin.Rudiak-Gould at cl.cam.ac.uk
Sat Feb 4 08:22:48 EST 2006
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
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 , but I don't know how best to expose it in Haskell.
More information about the Haskell-prime