On 12/4/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: > When you see an expression of the form: > > f a > > you generally want to evaluate a before applying; but if a is _|_, this > will only give the correct result if f a = _|_. Merely 'guaranteed to > evaluate' misses out on some common cases, for instance ifac: > > ifac 0 a = a > ifac n a = ifac (n - 1) (a * n) > > ifac is guaranteed to either evaluate a, or go into an infinite loop - > so it can be found strict, and unboxed. Whereas 'ifac -1 (error "moo")' > is an infinite loop, so using a definition based on evaluation misses > this case.
By this line: you generally want to evaluate a before applying; but if a is _|_, this will only give the correct result if f a = _|_ I assume you mean that it's generally more efficient to do things that way, because the calling function may have more information about "a" or how it is calculated, so you may be able to optimize better by doing eager evaluation whenever it is correct. Your ifac example makes perfect sense, thanks. -- ryan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
