`base-compat` module `Data.Foldable1.Compat` does not export `Foldable1`

[andreasabel]

I am puzzled by this error:

Module ‘Data.Foldable1.Compat’ does not export ‘Foldable1’

$ cabal build -w ghc-9.2.8   
...
src/full/Agda/Syntax/Abstract/Views.hs:10:31: error:
    Module ‘Data.Foldable1.Compat’ does not export ‘Foldable1’
   |
10 | import Data.Foldable1.Compat (Foldable1(foldMap1)) -- Foldable1 is in base from GHC 9.6 up
   |                               ^^^^^^^^^^^^^^^^^^^
Error: [Cabal-7125]
Failed to build Agda-2.9.0 (which is required by exe:agda-tests from Agda-2.9.0).

$ cabal-plan fingerprint | grep compat          
... G base-compat-0.14.1
... G foldable1-classes-compat-0.1.2

Isn't the whole point of the base-compat package to make newer additions to base available on older GHCs?
How can module Data.Foldable1.Compat exist and not export Foldable1?

Looking e.g. at https://hackage.haskell.org/package/base-compat-0.13.1/docs/Data-Foldable1-Compat.html this module seems to export nothing.
(But this package has been created by haddock which is beyond broken so I would not trust anything it claims...)

[RyanGlScott]

This is by design. As documented here, base-compat intentionally does not backport type classes that were introduced in more recent versions of base. If you want to a version of base-compat that re-exports a backported version of Foldable1 (by depending on the external foldable1-classes-compat package), then you'll need to use base-compat-batteries instead.

[andreasabel]

Thanks for the swift clarification!

I guess there is some motivation why module Data.Foldable1.Compat exists even though it is empty. What is the motivation?

[RyanGlScott]

This is an extreme case of how base-compat's no-external-dependencies policy is applied.

A perhaps more convincing example dates back to when the Semigroup class was first added to the Prelude. Back then, we had a similar problem: how should base-compat handle the fact that Semigroup did not exist in old versions of base (and could only be obtained by depending on the external semigroups library)? Ultimately, we decided that base-compat would export Semigroup from Prelude.Compat when building with versions of base that defined it, and for old versions of base, Prelude.Compat wouldn't export Semigroup at all. This means that Prelude.Compat would continue to exist when building with any version of base, but its API would be conditional.

Data.Foldable1.Compat is in a similar position: it is always provided, but its API is conditional depending on which version of base you are using. If you want to depend on base-compat (and not base-compat-batteries), you'll have to know which version of base introduced the Foldable1 class, as we cannot export it without relying on an external compatibility shim.

[andreasabel]

Thanks for the explanation.
So if I understand correctly, the version number of base-compat does not determine its API. Which means that base-compat is not a PVP-compliant library.
In contrast, base-compat-batteries would be such, and the general advice would be to use the latter rather than the former.

[RyanGlScott]

So if I understand correctly, the version number of base-compat does not determine its API. Which means that base-compat is not a PVP-compliant library.

base-compat is a very weird library in that its API is largely a function of what base's API is, so changes in base can have large impacts on base-compat simply because of how many re-exports base-compat has. I'm not really sure how to quantify things in terms of the PVP, but I wouldn't be surprised if base-compat were subtly violating some PVP promises. (Hard to avoid with a library designed like this, I'm afraid.)

In contrast, base-compat-batteries would be such, and the general advice would be to use the latter rather than the former.

base-compat-batteries may be a better fit depending on your use case, but it does have the downside that it incurs extra dependencies. Caveat emptor.