Skip to content

Conversation

@TeofilC
Copy link
Contributor

@TeofilC TeofilC commented Oct 10, 2025

This new boot library should be more stable than template-haskell and
should eventually allow us to remove much of the CPP around TH.

It will also make it easier for end-users to reinstall template-haskell
as it will no longer be used by any boot libraries

This GHC MR tests this PR against GHC-HEAD: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14978

@TeofilC TeofilC force-pushed the wip/th-lift branch 2 times, most recently from 4ccd3a1 to ad2e782 Compare October 16, 2025 22:14
@treeowl
Copy link
Contributor

treeowl commented Oct 16, 2025

Why doesn't the new package support older GHC versions? The CPP seems a bit blecherous.

@TeofilC
Copy link
Contributor Author

TeofilC commented Oct 16, 2025

template-haskell-lift is compatible with GHC>=8.10. But it is only a boot library with GHC>=9.14. So you wouldn't be able to backport new releases of containers to older GHCs as a boot lib (they would build fine from Hackage though).

Let me know what you'd prefer.
Either we can:

  • raise minimum GHC version to 8.10, use th-lift, cannot backport to minor versions of GHC before 9.14
  • Add CPP and only use th-lift when GHC is >=9.14

Eventually though, template-haskell-lift should let us remove all the TH CPP since that should all in that package.

@treeowl
Copy link
Contributor

treeowl commented Oct 16, 2025

That's only a potential issue for new releases on old GHC branches, right? I suppose it would be okay to have some CPP temporarily to support that as long as such branches are "supported" by GHC HQ. But wouldn't it be cleaner to just add template-haskell-lift as a boot package in those releases?

@TeofilC
Copy link
Contributor Author

TeofilC commented Oct 17, 2025

Yeah I agree that would be optimal. Unfortunately I don't think we can add new boot libs in minor releases (but I'll ask) since that can be disruptive.

I can commit to removing this CPP when it's no longer necessary though.

@TeofilC TeofilC force-pushed the wip/th-lift branch 2 times, most recently from 150bcfc to cb380cd Compare January 10, 2026 20:50
@TeofilC TeofilC marked this pull request as ready for review January 10, 2026 20:51
@TeofilC
Copy link
Contributor Author

TeofilC commented Jan 10, 2026

Now that GHC-9.14 is released we can test this.

@treeowl
Copy link
Contributor

treeowl commented Jan 10, 2026

Any idea what's going wrong with MucroHs? It smells like a CPP formatting issue, but I can't find it.

@TeofilC
Copy link
Contributor Author

TeofilC commented Jan 10, 2026

Any idea what's going wrong with MucroHs? It smells like a CPP formatting issue, but I can't find it.

I think that it doesn't like the elif syntax in the .cabal file? I'm not sure though

Copy link
Contributor

@meooow25 meooow25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The MicroHs version was updated in #1177. Hopefully the CI will pass after a rebase.

import Control.Monad.Fix (MonadFix (..))
import Test.Tasty.HUnit
import Test.ChasingBottoms.IsBottom (isBottom)
# if __GLASGOW_HASKELL__ >= 914
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is minor, but let's not have spaces after #. I think it would be less surprising (I'm surprised to learn that this is acceptable syntax).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it doesn't belong here, but in nested conditions it's very helpful to see what's going on visually.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot. That was a copy-paste error

# if __GLASGOW_HASKELL__ >= 914
import Language.Haskell.TH.Lift (Lift(..))
# else
import Language.Haskell.TH.Syntax (Lift(..))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change from Lift to Lift(..)? Same for other files.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's needed yeah.

import Language.Haskell.TH ()
import Data.Coerce (coerce)
# endif
import Data.Coerce
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change this line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo. Fixed now

# else
import Language.Haskell.TH.Syntax (Lift(..))
-- See Note [ Template Haskell Dependencies ]
import Language.Haskell.TH ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we don't need this any more if we depend on template-haskell-lift? The current reason is documented in note-template-haskell-deps.md

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep in fact we haven't needed it since GHC 9.12, I think, when these things moved to ghc-internal from template-haskell

This new boot library should be more stable than template-haskell and
should eventually allow us to remove much of the CPP around TH.

It will also make it easier for end-users to reinstall template-haskell
as it will no longer be used by any boot libraries
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants