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
