specify call-by-need

[Scott Turner]

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