Add Lift ByteString instances

[phadej]

See e.g. https://hackage.haskell.org/package/th-lift-instances-0.1.18/docs/src/Instances.TH.Lift.html#line-267

[Bodigrim]

See also bennofs/th-lift-instances#23

Is this feature worth to incur an additional dependency on template-haskell?

[phadej]

Is this feature worth to incur an additional dependency on template-haskell?

Yes.

[Bodigrim]

Thanks for the explanation, very convincing.

Given poor compatibility between releases of template-haskell package, I'm hesitant to agree blindly that defining instance Lift ByteString in bytestring brings more benefits than it causes headache. Even at this point it looks like one should use mkBytes with template-haskell >= 2.16, ByteString.unpack with template-haskell >= 2.8 and ByteString.Char8.unpack otherwise. This is a non-negligable amount of CPP.

Not that I have a set-in-stone attitude against it, I just do not use TemplateHaskell and do not know much about it.

[phadej]

Lifting of ByteString via TH is done very often. E.g. https://hackage.haskell.org/package/file-embed-0.0.13.0/docs/Data-FileEmbed.html#v:embedFile

embedFile :: FilePath -> Q Exp
embedFile fp =
#if MIN_VERSION_template_haskell(2,7,0)
    qAddDependentFile fp >>
#endif
  (runIO $ B.readFile fp) >>= bsToExp

bsToExp is lift.

Similar function is in th-lift-instances and who knows where because authors are not aware of other implementations or don't want depend on packages "just for one function". Having Lift ByteString in bytestring would allow packages converge to use the same implementation (and contributors improve single one).

Given poor compatibility between releases of template-haskell package, ...

That is not different from problems th-lift-instances maintainer(s) go through. Which in practice is probably @RyanGlScott propagating those changes downstream (after changing something in Template Haskell).

[Bodigrim]

OK, makes sense.