Switch from template-haskell to template-haskell-lift

[TeofilC]

We switch our dependency on template-haskell to a dependency on template-haskell-lift. This smaller library is more stabler. If we can remove the template-haskell dependency from all boot libraries then template-haskell will be much easier to re-install since it no longer needs to be in GHC's dependency closure.

For more information see the GHC proposal that introduced this library: ghc-proposals/ghc-proposals#696

This GHC MR tests this PR against GHC-HEAD: https://gitlab.haskell.o

[Bodigrim]

We strive for new releases to be backportable to older GHC major series, which do not yet have template-haskell-lift as a boot library. To keep it possible, I imagine you need something like

if impl(ghc>9.15)
  build-depends: template-haskell-lift
else 
  build-depends: template-haskell 

[TeofilC]

Good point. template-haskell-lift itself is buildable with older major versions (where it just re exports tenplate-haskell) but unless we backport it as a boot library to those versions then indeed you wouldn't be able to use the new bytestring as a boot library.

I'll implement what you suggest

[Bodigrim]

@TeofilC please rebase.

[Bodigrim]

@TeofilC could you please raise a draft GHC MR, which updates bytestring submodule to your commit? Otherwise I cannot test it.

[TeofilC]

Since I last looked at this, bytestring has gained a dependency on liftCode. This is not exposed by template-haskell-lift, so for now this PR is stalled.

This shows a gap in the interface of template-haskell-lift. Exporting unsafeCodeCoerce from template-haskell-lift should allow this code to be written. I didn't spot this when designing the interface since so few people use the typed TH API, but this is a reasonable thing to want.

[TeofilC]

Actually we can just use error and we get a similar message!

[TeofilC]

Not sure about the CI failure on 9.0. I can't reproduce it locally

[Bodigrim]

Not sure about the CI failure on 9.0. I can't reproduce it locally

It's unrelated to your changes, I have the same failure in #718 (comment).

[TeofilC]

Anything I can do to move this along ?

[Bodigrim]

@TeofilC if you have time to figure out what’s up with the CI, it would help to speed things up.

[TeofilC]

I tried to have a quick look but had little luck. I tried building locally with GHC-9.0.2 and it seems to run the test suite fine.

Perhaps it's something like a broken cache or some oddness about the github runner env?

[Bodigrim]

Could you rebase and trigger a fresh CI run?

[TeofilC]

Interesting now we are getting this failure on 9.2. When running it locally, I was getting this too:

 *** Failed! Exception: './lazy-hclose-test7457-300.tmp: withFile: resource busy (file is locked)' 

[TeofilC]

I see fixed on the other PR

[Bodigrim]

There seems to be a bunch of warnings "The import of ‘Language.Haskell.TH.Syntax’ is redundant" for GHC < 9.14.

[TeofilC]

There seems to be a bunch of warnings "The import of ‘Language.Haskell.TH.Syntax’ is redundant" for GHC < 9.14.

Fixed now, we only needed that import before <9.0

[hsyl20]

LGTM

[Bodigrim]

I think this is a roundabout way to express the idea. Could we use #ifdef MIN_VERSION_template_haskell_lift instead? And then it's up to bytestring.cabal whether template-haskell-lift is available in a given build configuration.

Similar below, and I'd prefer #if MIN_VERSION_template_haskell(2,16,0) || defined(MIN_VERSION_template_haskell_lift) to __GLASGOW_HASKELL__ >= 810.

[Bodigrim]

@TeofilC just a gentle reminder.

[TeofilC]

Thanks for the ping. I had completely forgotten about this!

[TeofilC]

I've implemented this in a slightly different way to what you suggest. Hopefully it's a bit simpler

[Bodigrim]

Thanks @TeofilC!