zipWith' to packZipWith as per #208

[elikoga]

Renames zipWith' to packZipWith and exports it
Recovers test cases for packZipWith from comments

A PR renaming zipWith' to packZipWith and exporting it would be welcome.
Originally posted by @Bodigrim in #208 (comment)

All test cases pass

[Bodigrim]

Cool! Please do the same for Data.ByteString.Char8, Data.ByteString.Lazy and Data.ByteString.Lazy.Char8.

[elikoga]

Cool! Please do the same for Data.ByteString.Char8, Data.ByteString.Lazy and Data.ByteString.Lazy.Char8.

I'm not sure how comfortable I am replicating packZipWith given that there is no original zipWith' in those modules to rename and the version in Data.ByteString uses unsafeDupablePerformIO. I might play around with it a bit later though unless you've got a different idea.

[elikoga]

I added packZipWith to Data.ByteString.Char8 since the function from Data.ByteString only requires Storable a.

[Bodigrim]

You can impement packZipWith for lazy bytestrings using packZipWith for strict bytestrings. Zip data Chunk by Chunk. Here is an example of this technique:

bytestring/Data/ByteString/Lazy/Internal.hs

Lines 251 to 265 in d701a2a

	cmp :: ByteString -> ByteString -> Ordering
	cmp Empty Empty = EQ
	cmp Empty _ = LT
	cmp _ Empty = GT
	cmp (Chunk a@(S.BS ap al) as) (Chunk b@(S.BS bp bl) bs) =
	case compare al bl of
	LT -> case compare a (S.BS bp al) of
	EQ -> cmp as (Chunk (S.BS (S.plusForeignPtr bp al) (bl - al)) bs)
	result -> result
	EQ -> case compare a b of
	EQ -> cmp as bs
	result -> result
	GT -> case compare (S.BS ap bl) b of
	EQ -> cmp (Chunk (S.BS (S.plusForeignPtr ap bl) (al - bl)) as) bs
	result -> result

[elikoga]

On it

[Bodigrim]

Great! Please add tests for new functions.

[elikoga]

Great! Please add tests for new functions.

I've only added test cases where there were ones for the packZipWith previously. If there are any more needed just ask

[sjakobi]

LGTM!

[sjakobi]

How about adding a RULE similar to the one for the strict version?

[elikoga]

Given that in future we intend to decomission the rewrite rule, we can probably remove the sentence advertising it already.

• Bodigrim

Don't know how I feel about adding a rule only for it to be decommisioned later, still added the rule to Data.ByteString,Lazy though

[Bodigrim]

@sjakobi As discussed in #208, such rule is harmful when the output of zipWith is consumed lazily. We cannot drop the existing rule for strict zipWith lightly, without further discussion, but from my perspective we should not introduce it for lazy bytestrings.

[Bodigrim]

Instead of copying a rule from the strict version, I would rather add

{-# RULES "Specialise zipWith" pack (zipWith f p q) = packZipWith f p q #-} 

(both for strict and lazy bytestrings)

[elikoga]

After reading #208 again I agree. I changed the rewrite rule

[elikoga]

Data/ByteString.hs:1649:1: warning: [-Winline-rule-shadowing]
    Rule "ByteString specialise zipWith" may never fire
      because ‘pack’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘pack’
     |
1649 | "ByteString specialise zipWith" forall (f :: Word8 -> Word8 -> Word8) p q .
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

GHC is complaining. I'm not that read up on the inline/noinline pragmas. What needs to be changed?

[elikoga]

I added {-# INLINE [1] pack #-} to Data.ByteString and Data.ByteString.Lazy since they only resolve to packBytes and I'm sure it would get inlined anyways.

I added {-# INLINE [1] zipWith #-} to Data.ByteString.Lazy but I'm not so sure about the performance characteristics of that. Shouldn't be too big of an issue since it just resolves to go a as b bs.

[Bodigrim]

Thanks for experimenting. I don't mind {-# INLINE [1] zipWith #-}, but not quite sure about {-# INLINE [1] pack #-}. It seems innocent, but deserves a thorough investigation of the impact, because pack is used pretty much everywhere.

To stop going down the rabbit hole, let's reset back to d93cdd4 and be with it for now. Rules issue can be resolved in a separate PR later. Sorry that it became so laborious.

[sjakobi]

Apologies for the confusion – I had missed the discussion in #208.

[Bodigrim]

@elikoga Thanks, well done!