change of strictness in zipWith
$ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined [] $ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined I found the difference because my mapAdjacent function uses 'tail' in the second argument of 'zipWith': mapAdjacent :: (a -> a -> b) -> [a] -> [b] mapAdjacent f xs = zipWith f xs (tail xs) I get: $ ghci-7.10.0.20141227 -Wall *Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int]) *** Exception: Prelude.tail: empty list
This is a big deal. That's a very common pattern. On 02/01/15 11:50, Henning Thielemann wrote:
$ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined []
$ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined
I found the difference because my mapAdjacent function uses 'tail' in the second argument of 'zipWith':
mapAdjacent :: (a -> a -> b) -> [a] -> [b] mapAdjacent f xs = zipWith f xs (tail xs)
I get:
$ ghci-7.10.0.20141227 -Wall *Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int]) *** Exception: Prelude.tail: empty list _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
This is a big deal. That's a very common pattern.
However, I checked the Haskell 98 report (chapter 8, standard Prelude, PreludeList, page 120 in the PDF) and found that the new behaviour matches the specified one: zipWith :: (a -> b -> c) -> [a] -> [b] -> [c] zipWith z (a:as) (b:bs) = z a b : zipWith z as bs zipWith _ _ _ = []
I don't think it does. The first pattern (a:as) will be refuted, and the second (b:bs) won't try to match at all. On 02/01/15 12:00, Henning Thielemann wrote:
On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
This is a big deal. That's a very common pattern.
However, I checked the Haskell 98 report (chapter 8, standard Prelude, PreludeList, page 120 in the PDF) and found that the new behaviour matches the specified one:
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c] zipWith z (a:as) (b:bs) = z a b : zipWith z as bs zipWith _ _ _ = []
On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
I don't think it does. The first pattern (a:as) will be refuted, and the second (b:bs) won't try to match at all.
right - stupid me Then, the new behavior of zipWith is really a bug. I added a ticket: https://ghc.haskell.org/trac/ghc/ticket/9949
It was done intentionally, to avoid having the zipWith semantics depend on
which, if either, of the venerable foldr2 RULES fired. But I'd personally
be very happy to just nix the shady rule (the other is fine), and accept
the performance penalty.
On Jan 2, 2015 5:24 AM, "Henning Thielemann"
On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
I don't think it does. The first pattern (a:as) will be refuted, and the
second (b:bs) won't try to match at all.
right - stupid me
Then, the new behavior of zipWith is really a bug. I added a ticket:
https://ghc.haskell.org/trac/ghc/ticket/9949 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (3)
-
David Feuer -
Henning Thielemann -
Roman Cheplyaka