Lazy zip is stricter than expected

[clyring]

I expect BL.zip x y to be equivalent to List.zip (BL.unpack x) (BL.unpack y). And yet if x = BL.replicate 2 0 <> error "lazy tail" and y = BL.singleton 0 we observe the former to be (0, 0) : error "lazy tail" and the latter to be (0, 0) : [].

[Bodigrim]

I'm not sure if this is fine to go into 0.12 series, kinda a change of behavior, even if minor and benign. Removing a milestone for now.

[clyring]

I think it's fine to backport. We have included similar laziness-increasing changes in other recent minor releases:

• Lazier unlines #477 in 0.11.3.0
• Make Data.ByteString.Lazy.Char8.lines less strict #562 in 0.11.4.0
• Implement stimes for Builder and ShortByteString #611, Explicitly implement sconcat in Semigroup instances #650, and (most of) Implement instance Data #614 in 0.12.1.0

The old strictness behavior for Lazy.zip and Lazy.zipWith strikes me as an outright bug. It is the following:

• Before (potentially) examining the second byte of any input chunk, force the next chunk of the same input bytestring.

And that behavior...

• was rather arbitrary
• was not documented
• seems to have no benefits whatsoever

And of course internal-chunk-boundary-dependent strictness means that the old behavior can distinguish between "equal" LazyByteStrings:

ghci> import qualified Data.ByteString.Lazy as BL
ghci> import qualified Data.ByteString as BS
ghci> let x = BL.repeat 0
ghci> let y1 = BL.take 10000 x
ghci> let y2 = BL.replicate 10000 0
ghci> y1 == y2
True
ghci> map (map BS.length . BL.toChunks) [y1, y2]
[[4080,4080,1840],[1840,4080,4080]]
ghci> last $ take 8000 $ BL.zip x (y1 <> undefined)
(0,0)
ghci> last $ take 8000 $ BL.zip x (y2 <> undefined)
*** Exception: Prelude.undefined
CallStack (from HasCallStack):
  undefined, called at <interactive>:9:36 in interactive:Ghci9

[Bodigrim]

Fair enough, backported.