2009/11/6 Keith Sheppard :

Also, an nice way to check how evaluation works in ghci is to do something like:

...

if False && error "error here" then "it's true" else "it's false"

This expression will evaluate as "it's false" without any "error here" error message appearing

On Thu, Nov 5, 2009 at 9:05 PM, Nathan M. Holden wrote:

...

If you have an if statement like

if (a&&b) then fun else fun'

and a is false, does GHC actually bother to check b?

Note that Haskell is far from the only programming language that is smart about this. I actually can't think of a single programming language implementation that I know of which isn't this smart... For what it's worth, Haskell (and others) is smart about ORs as well. In (x || y), y will only be evaluated if x is False. -- Deniz Dogan

On Fri, Nov 6, 2009 at 10:03 AM, Deniz Dogan wrote:

...

...

If you have an if statement like

if (a&&b) then fun else fun'

and a is false, does GHC actually bother to check b?

Note that Haskell is far from the only programming language that is smart about this. I actually can't think of a single programming language implementation that I know of which isn't this smart...

For what it's worth, Haskell (and others) is smart about ORs as well. In (x || y), y will only be evaluated if x is False.

Right, almost every programming language act this way, which is why (&&) and (||) are sometimes called short-circuit boolean operators. What's interesting is not that Haskell does it for (&&) and (||), it's that those operators aren't primitives in Haskell but normal functions defined in the Prelude, their behavior is just lazy evaluation at work... That's also why you can write the functions and() and or() as easily as : and :: [Bool] -> Bool and = foldr (&&) True or :: [Bool] -> Bool or = foldr (||) False And get a nice short-circuiting behavior.... -- Jedaï