specify call-by-need

[John Meacham]

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 <2haskell at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>