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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
