New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-export Foldable1
and Bifoldable1
from base-4.18
(GHC 9.6)
#130
Comments
I think the plan was to release https://github.com/phadej/foldable1 as a compatibility shim, then make |
I'll be happy if someone takes over |
EDIT: I guess it can, as |
I don't have a strong opinion on whether to put the compatibility shims into |
I'd say that's something CLC should arrange together with Hackage admins. @strake donated the name for the cause in 2019: https://mail.haskell.org/pipermail/libraries/2019-October/030029.html @Bodigrim asked @strake to confirm whether that's offer still stands in 2021 in haskell/core-libraries-committee#9 (comment) but AFAICS didn't got a confirmation (nor prohibition!) But as said, So I don't see a road block for taking over the package name. One can of course be polite and ask once more, but OTOH if @strake removed themselves from a maintainer group and deprecated the package, I'd say that the offer made in 2019 still stands. |
It would be better to have a separate shim package so that users who are interested in I assume that @strake deprecated the package and stepped down as a maintainer (leaving the package without any active maintainers), so it should be fine to take over. If someone is serious about maintaining a compatibility package, I'd be happy to assist asking Matthew again and helping with admin matters. |
I think https://github.com/phadej/foldable1 would be a good candidate for a shim package. @phadej, would you be willing to transfer ownership of that repository to the @Bodigrim, is the package takeover process described here up to date? If so, I can initiate it by emailing @strake. |
Sure. |
Thanks, @phadej! Let me know if I can help with anything transfer-wise. |
@RyanGlScott I'll first transfer it to you, as IIRC one needs to be an admin of org to transfer the repositories there. |
@RyanGlScott and also it might be required to move (Say if |
A very good point. I can see how Really, I think the issue is that the
If you were to strip away all of this extra functionality, however, then
Does this sound reasonable? If we wanted to, we could even rename the |
That's an option too. For some reason I'd still rather put EDIT: A benefit of having |
I favor putting
|
I was thinking what happens if e.g.
There might be very distant, "what if |
Indeed, classes migrating from the Kmettiverse to |
This moves all of the compatibility modules in `bifunctors` (`Data.Bifunctor`, `Data.Bifoldable`, and `Data.Bitraversable`) to a new `bifunctor-classes-compat` package. This package has fewer dependencies than `bifunctors` proper. This is one step towards being able to use `Bifunctor` in an upcoming `foldable1-classes-compat` compatibility package. See ekmett/semigroupoids#130. This is purely a refactoring, and there should be no change in user-visible behavior.
This moves all of the compatibility modules in `bifunctors` (`Data.Bifunctor`, `Data.Bifoldable`, and `Data.Bitraversable`) to a new `bifunctor-classes-compat` package. This package has fewer dependencies than `bifunctors` proper. This is one step towards being able to use `Bifunctor` in an upcoming `foldable1-classes-compat` compatibility package. See ekmett/semigroupoids#130. This is purely a refactoring, and there should be no change in user-visible behavior.
This moves all of the compatibility modules in `bifunctors` (`Data.Bifunctor`, `Data.Bifoldable`, and `Data.Bitraversable`) to a new `bifunctor-classes-compat` package. This package has fewer dependencies than `bifunctors` proper. This is one step towards being able to use `Bifunctor` in an upcoming `foldable1-classes-compat` compatibility package. See ekmett/semigroupoids#130. This is purely a refactoring, and there should be no change in user-visible behavior.
I've started an attempt to split out -- By manually generating these names we avoid needing to use the
-- TemplateHaskell language extension when compiling the bifunctors library.
-- This allows the library to be used in stage1 cross-compilers.
bifunctorsPackageKey :: String
#ifdef CURRENT_PACKAGE_KEY
bifunctorsPackageKey = CURRENT_PACKAGE_KEY
#else
bifunctorsPackageKey = "bifunctors-" ++ showVersion version
#endif
mkBifunctorsName_tc :: String -> String -> Name
mkBifunctorsName_tc = mkNameG_tc bifunctorsPackageKey
mkBifunctorsName_v :: String -> String -> Name
mkBifunctorsName_v = mkNameG_v bifunctorsPackageKey
bimapConstValName :: Name
bimapConstValName = mkBifunctorsName_v "Data.Bifunctor.TH.Internal" "bimapConst"
bifoldrConstValName :: Name
bifoldrConstValName = mkBifunctorsName_v "Data.Bifunctor.TH.Internal" "bifoldrConst"
-- ... On modern GHCs, none of this is necessary, as you can simply use the There is a catch to this trick, however: it only works for things defined either in (1) the I'm a bit stumped at how best to handle this. Some options include:
|
Sadly haskell/cabal#7027 haven't got implemented, now it would been handy |
I don't think having Unfortunate, but could perfectly live with. |
I was wondering. Is it actually true that I wonder if i should open a GHC issue to resolve that eventually |
Sounds good to me. I'll go with that plan, then.
Not that I am aware of. The only ways I know to look this information up are:
If I understand what you're asking, none of these would satisfy your criteria. |
Yeah, it's not great. Of course one could But OTOH threading the pkgname through all of the TH code is extra work... |
This moves the `Data.Bifunctor.TH` module, as well as all of the compatibility modules in `bifunctors` (`Data.Bifunctor`, `Data.Bifoldable`, and `Data.Bitraversable`) to a new `bifunctor-classes-compat` package. This new package has fewer dependencies than `bifunctors` proper. This is one step towards being able to use `Bifunctor` in an upcoming `foldable1-classes-compat` compatibility package. See ekmett/semigroupoids#130. This is purely a refactoring, and there should be no change in user-visible behavior.
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1` to `base`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1` to `base`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, dependending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. (TODO RGS: Actually do this!) Fixes #130.
I've made some more progress on this:
While prototyping a patch for semigroupoids/src/Data/Semigroup/Foldable.hs Lines 17 to 28 in b9151e7
The tricky part is that there are several differences between the API exported from
Should we make an effort to make the |
We can think that E.g. I'd
|
Another thing I've realized is that if we want to depend on a sufficiently new version of |
This is a prerequisite for later changes planned in #130, where we will need to bump the lower version bounds on `bifunctors` to bring in the changes from ekmett/bifunctors#111.
This is a prerequisite for later changes planned in #130, where we will need to bump the lower version bounds on `bifunctors` to bring in the changes from ekmett/bifunctors#111.
#131 drops pre-8.0 GHC support. |
This is a prerequisite for later changes planned in #130, where we will need to bump the lower version bounds on `bifunctors` to bring in the changes from ekmett/bifunctors#111.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, dependending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. (TODO RGS: Actually do this!) Fixes #130.
#132 is a draft PR that migrates |
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, depending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. (TODO RGS: Actually do this!) Fixes #130.
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1` to `base`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
GHC 9.6.1-alpha3 is now out, and I believe I've put |
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
(This cherry-picks #115 to the `main` branch.) This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, depending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. (TODO RGS: Actually do this!) Fixes #130.
(This cherry-picks #115 to the `main` branch.) This is part of an effort to adapt to [this Core Libraries Proposal](haskell/core-libraries-committee#9), which adds `Foldable1` and `Bifoldable1`. This is a prerequisite for re-exporting these classes from `semigroupoids`; see ekmett/semigroupoids#130.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, depending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. Fixes #130.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, depending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. * Bump primary version number to 6. This is done out of an abundance of caution to warn users that they may need to migrate existing code that defines `Foldable1` instances without implementations of `foldMap1`. See the `CHANGELOG` entry for the full details. Fixes #130.
This patch: * Re-exports the `Foldable1` and `Bifoldable` classes from `base` or `foldable-classes-compat`, depending on which version of `base` is being used. * Migrates the `Foldable1` and `Bifoldable1` instances to their respective downstream packages. I have bumped the lower version bounds on `bifunctors` and `tagged` to ensure that they always provide these instances. * Bump primary version number to 6. This is done out of an abundance of caution to warn users that they may need to migrate existing code that defines `Foldable1` instances without implementations of `foldMap1`. See the `CHANGELOG` entry for the full details. Fixes #130.
I've uploaded |
base-4.18.0.0
(bundled with GHC 9.6) implements this CLC proposal (see this GHC commit), which addssemigroupoids
'Foldable1
andBifoldable1
classes tobase
. We should re-export these classes when building with a sufficiently new version ofbase
, and provide backported versions of these classes when building with older versions ofbase
. Note that the API of these classes inbase
have changed somewhat from their current form insemigroupoids
, so we will need to make some API changes on thesemigroupoids
end.After doing this, we can close the following issues, as they are now
base
issues rather thansemigroupoids
issues:It would also resolve some parts of #26, but there are certainly other parts of
semigroupoids
to bikeshed besidesFoldable1
andBifoldable1
.The text was updated successfully, but these errors were encountered: