[andreasvc]

&& and || are evaluated by first looking at the left operand, then at the right. That seems pretty strict to me. You're thinking of their short-circuit nature, that the right operand is not always evaluated; I believe that that is a different issue than strict vs. lazy.

[gizmo686]

Consider '||' as a normal function. Consider ||(f(x),g(x)). If this were strictly evaluated, we would compute f(x) and g(x), then pass them as arguments to ||. Instead, we compute f(x) pass it to ||, and compute g(x) only if it is needed. This is lazy evaluation.

[andreasvc]

Well, the Boolean operators in C-like languages are NOT normal functions, which is the point. Furthermore, what is strict about them is the order in which their operands are evaluated, which is a different aspect than the one you mention: whether all arguments are evaluated before considering the function. Consider e.g., notUnderAttack() || enableDoomsdayDevice(). A lazy language is free to decide that it's more optimal to evaluate the second operand first.

[gizmo686]

I don't think a lazy language can necessarily make that decision. Consider the simple implementation of ||:

  ||(f,g){
    if (eval(f)) then return true
    if (eval(g)) then return true
    return false
  }

A lazy language will not evaluate a function until it knows it needs it. In this implementation, there is no way of knowing that g will be needed until after computing f, so f will be computed first. Having said that, it is possible for an optimizing compiler to realize that the order doesn't matter and make a decision on which one to check first, however that is an optimization that the compiler would need to prove does not change the results.

This seems like a good example of why purity seems to be really beneficial to lazy evaluation.

[voxfrege]

> Well, the Boolean operators in C-like languages are NOT normal functions, which is the point.

"Not normal", because the language is strict, and there is no way to make a lazy function on your own, even when it is so tremediously useful.

In other words, the C standard comittee decides which functions may be lazy. As a Haskell programmer, you decide.