Missing (Arbitrary) Solo instance with GHC-8.10 and GHC-9.0

[phadej]

The API is conditional. Please depend on https://hackage.haskell.org/package/OneTuple or bump lower on base, so Solo instances are always available.

[MaximilianAlgehed]

Another random compat package... No thanks.

[phadej]

Then bump the lower bound, i.e. drop support for GHC-8.10 and GHC-9.0 to have a non conditional API

[MaximilianAlgehed]

I don't see the reason not to support earlier GHC versions just because base changes every now and then.

I do see reasons not to pick random compat packages back and forth. Likewise, next release will likely remove data-array-byte precisely because of this random compat package nonsense. As I feared, opening the door a little bit blows it right open and the snowstorm of random compat packages published by random people that we supposedly have to depend on enters the vestibule.

[andreasabel]

@MaximilianAlgehed: The version number of a package should determine its API. The version numbers of its dependencies should not play a role here. I think this is the spirit of the Haskell PVP.

Instable APIs are very confusing, I think. Here is my own experience with this: haskell-compat/base-compat#102 (comment)

Reference:

quickcheck/src/Test/QuickCheck/Arbitrary.hs

Lines 1160 to 1169 in 19bf572

	#if MIN_VERSION_base(4,16,0)
	instance Arbitrary a => Arbitrary (Solo a) where
	arbitrary = mkSolo <$> arbitrary
	shrink = map mkSolo . shrink . getSolo
	instance CoArbitrary a => CoArbitrary (Solo a) where
	coarbitrary = coarbitrary . getSolo
	#endif

[MaximilianAlgehed]

@andreasabel as I've said before and as I will say again. The problem with this principle is that people are applying it across compiler versions.

My take is that the actual version number of any library in the haskell ecosystem is the product of the stated version number and the compilers version number.

The problems with NOT adhering to this principle are obvious. As long as compatibility packages for base are not published by a single source of truth but by a random selection of people where each new package is maintained by some new random github handle I've never heard of the scope for introducing either malicious or controversial dependencies is obvious.

This is a deficit of PVP and the ever-moving API of base that were not going to be able to fix in this repository.

[andreasabel]

@MaximilianAlgehed wrote:

My take is that the actual version number of any library in the haskell ecosystem is the product of the stated version number and the compilers version number.

Cabal does not support this philosophy well. Not sure how I should write the dependencies in my .cabal files in a reasonable way, if I have to cover several GHC versions. Do I have to have a if impl(ghc == ...) section for each major GHC version? And then maybe in the future also for each MHS version? Cabal does not allow cases on my base version.

[MaximilianAlgehed]

@andreasabel what's your use case for supporting multiple GHC versions while insisting on bleeding-edge features not present in all of them? If it's to support other supporting that use case, how will you deal with the inevitable case where there are two competing compatibility packages?

With my philosophy the choice of compat package and instance rests squarely on the end user.

[Bodigrim]

I'm chuffed to bits to be "some new random github handle I've never heard of", and I'm sure @phadej shares this feeling, but in truth QuickCheck has already depended on packages maintained by us for many years, so using data-array-byte and / or OneTuple does not require QuickCheck to extend its trust network.

how will you deal with the inevitable case where there are two competing compatibility packages?

I'm having hard time to recall a single instance of competing compatibility packages in Haskell ecosystem. Do you have any examples in mind? (I don't really expect to change the outcome of this discussion and I don't think it is productive to force your hand, I'm just being curious)

[MaximilianAlgehed]

The point is that I've not yet heard a single good argument in favour of compatibility packages and there are good arguments against.

I ask again, what binary are you compiling with and old and a new GHC version that desperately relies on cutting-edge base features?

For the record, it's presumptuous to think you can for my hand, @Bodigrim.

[andreasabel]

@MaximilianAlgehed wrote:

what's your use case for supporting multiple GHC versions while insisting on bleeding-edge features not present in all of them?

I can mirror this question back to you, since you insist on making QuickCheck-2.18 available to older GHCs, at the cost of offering them an incomplete API. Why would I need QuickCheck-2.18 with an old compiler, why couldn't I use an older version of QuickCheck with them?

If I understand your approach correctly, if collections would become part of base-4.23, you would bring over its Arbitrary instances into QuickCheck-2.19, but they would only be available with GHC 9.16. Say I hoogle the Arbitrary instances of QuickCheck-2.19, but the guy servicing me hoogle uses GHC 9.14 (or older) to haddock the API, I would not see these instances there. So depending on which tool I use to view the QC API, I get different results.

This is like reading a conference paper whose content changes with the type or version of the PDF reader I happen to use.

[MaximilianAlgehed]

I can mirror this question back to you, since you insist on making QuickCheck-2.18 available to older GHCs, at the cost of offering them an incomplete API. Why would I need QuickCheck-2.18 with an old compiler, why couldn't I use an older version of QuickCheck with them?

I don't understand this point at all. The API is complete w.r.t. the compiler version they're running and I think those stuck on old GHC versions for whatever reason deserve the latest features.

If I understand your approach correctly, if collections would become part of base-4.23, you would bring over its Arbitrary instances into QuickCheck-2.19

Correct.

Say I hoogle the Arbitrary instances of QuickCheck-2.19, but the guy servicing me hoogle uses GHC 9.14 (or older) to haddock the API, I would not see these instances there. So depending on which tool I use to view the QC API, I get different results.

Indeed. Likewise, if the library has dependent dependencies you will see a different list of dependencies depending on what version of GHC the server has. We can debate endlessly which problem is worse.

I concede that this is the first reasonable objection to my position anyone has put forward. However, the solution in this case is obvious: if you're depending on GHC 9.16 and you care about the bleeding edge features, you should make sure you're not looking at documentation for older compiler versions.

This is like reading a conference paper whose content changes with the type or version of the PDF reader I happen to use.

No, it's like reading a conference paper whose content depends on where you downloaded it from.

[sol]

Can we please keep the dependency footprint of QuickChek to the absolute minimum required!

Every dependency adds a cost, but for testing libraries a small dependency footprint is even more crucial as testing libraries are one of the first thing you want to get to work when:

• you experiment with a new (in development) version of GHC
• you develop a new Haskell compiler (e.g. MicroHs)

In addition, testing libraries, by their nature, are commonly required on CI. For larger projects you need dependency caching anyway, but for many smaller/foundational packages that only depend on boot libraries you don't need dependency caching, unless of course your testing dependencies take a long time to compile.

Finally, you wanna be able to use testing libraries to test a compiler, and in that scenario I really don't wanna deal with a handful of compat libraries, neither.

From what I understand, missing instances can go into quickchek-instances, no?