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