# if ands

 Classic List Threaded
7 messages
Reply | Threaded
Open this post in threaded view
|

## if ands

 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?
Reply | Threaded
Open this post in threaded view
|

## if ands

 No, consider the definition of (&&) -- I hope this is the def from the prelude. If it's not, then it's   probably isomorphic... (&&) :: Bool -> Bool -> Bool True  && x = x False && _ = False Since (&&) ignores it's second argument if the first is false, then it   will "Short circuit" (like most `&` operators in other languages) due   to lazy evaluation. /Joe On 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? > _______________________________________________ > Beginners mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

## if ands

 In reply to this post by Nathan M. Holden 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 <[hidden email]> 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? > _______________________________________________ > Beginners mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/beginners> -- keithsheppard.name
Reply | Threaded
Open this post in threaded view
|

## if ands

 2009/11/6 Keith Sheppard <[hidden email]>: > 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 > <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

## if ands

 As Haskell uses lazy evaluation so (&&) and if can be functions, as Joe Fredette said previously. In say Lisp which is strict if has to be a primitive / special form and (&&) is likely definable only with if (or implemented as another primitive). In some senses Haskell doesn't need to be smart to be 'smart'. Best wishes Stephen 2009/11/6 Deniz Dogan <[hidden email]>: > 2009/11/6 Keith Sheppard <[hidden email]>: > 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. >
Reply | Threaded
Open this post in threaded view
|

## if ands

 In reply to this post by Deniz Dogan-3 On Fri, Nov 6, 2009 at 10:03 AM, Deniz Dogan <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

## if ands

 In reply to this post by Deniz Dogan-3 On 06/11/09 09:03, Deniz Dogan wrote: > 2009/11/6 Keith Sheppard <[hidden email]>: >> 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 >> <[hidden email]> 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. IIRC Pascal isn't "smart" about it. /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus?therning?org          Jabber: magnus?therning?org http://therning.org/magnus         identi.ca|twitter: magthe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/beginners/attachments/20091106/d04f14f2/signature.bin