Yeah, you should absolutely mind the order of the parameters (or more generally, when the operation isn't commutative), the strictness of the function's second parameter. In this case, both (&&) and (||) are strict in their first parameter, but both "short circuit" if the first parameter is False/True, and don't evaluate their second parameter. The short-circuiting (via laziness) terminates foldr's traversal of the entire list structure and saves the program lots of work. By flipping the arguments, you're basically forcing testr' to traverse the entire list before saying what it knew from the beginning.
On Tue, Oct 11, 2011 at 10:45 PM, Frodo Chao <frodogr...@gmail.com> wrote: > Hi, > > I came upon this when playing with foldr and filter. Compare the two > definitions: > > testr n = foldr (\x y -> x && y) True [t | (_, t) <- zip [1 .. n] [True, > True ..]] > testr' n = foldr (\x y -> y && x) True [t | (_, t) <- zip [1 .. n] [True, > True ..]] > > I tried these functions on ghci (The Glorious Glasgow Haskell Compilation > System, version 7.0.3), and get the following results (with :set +s): > > testr 1000000 => True > (0.01 secs, 7920832 bytes) > testr' 1000000 => True > (8.72 secs, 446585344 bytes) > > This bizarre (at least to me) behavior also applies to ||. Should I mind > the orderings of the parameters (especially the accumulator) in the function > passed to foldr? > > Thak you for reading. > > Sincerely yours, > Frodo Chao > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
