Except for the fact that compilers don't actually implement call by need. An example would be the speculative evaluation of ghc. http://research.microsoft.com/en-us/um/people/simonpj/papers/optimistic/adap... And local optimizations that affect asymptotic behavior are used all the time, to the point they are vital for a functioning compiler. The tail-call optimization turning O(n) space usage to O(1) being a prime example. And what is meant by "call-by-need" in the presence of exceptions and concurrency is not entirely obvious. I think that specifying call-by-need would be more confusing and contrary to what actually exists in the wild. John On Tue, Feb 15, 2011 at 5:53 PM, Scott Turner <2haskell@pkturner.org> wrote:

In practice, Haskell a call-by-need language.  Still, software developers are not on firm ground when they run into trouble with evaluation order, because the language definition leaves this open. Is this an underspecification that should be fixed?

 1. Haskell programmers learn the pitfalls of sharing as soon     as they cut their teeth on 'fib',  2. Virtually all significant-sized Haskell programs rely on     lazy evaluation and have never been tested with another     evaluation strategy,  3. Questions come up on Haskell-Café, infrequently but regularly,     regarding whether a compiler optimization has altered sharing     of values within a program, causing it to fail,  4. The rationale for the monomorphism restriction assumes     lazy evaluation,  5. It is the effect on asymptotic behavior that matters,  6. Portable Haskell code should not have to allow for the     variety of non-strict evaluation strategies, as the Haskell     Report currently implies.

I suggest specifying call-by-need evaluation, allowing for the places where type classes prevent this.  If necessary, make it clear that local optimizations not affecting asymptotic behavior are permitted.

This would not eliminate struggles with evaluation order. The intent would be to clarify expectations.

-- Scott Turner

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On 16 Feb 2011, at 01:53, Scott Turner wrote:

In practice, Haskell a call-by-need language. Still, software developers are not on firm ground when they run into trouble with evaluation order, because the language definition leaves this open. Is this an underspecification that should be fixed?

I might actually be inclined to go the other way in the language spec. The Report says the language is "non-strict", but there is at least one implementation in the wild which is basically strict (with escape hatches for explicit laziness). Compatibility with Haskell in all other aspects (apart from evaluation order) is a nice property.

2. Virtually all significant-sized Haskell programs rely on lazy evaluation and have never been tested with another evaluation strategy,

Having personally converted a reasonable number of modules/programs from Haskell to this "strict" Haskell implementation, I can verify that the change in evaluation strategy does indeed throw up several surprises. None are insurmountable, but writing for a strict evaluator does require a different way of thinking about some program structuring. Regards, Malcolm