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

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

Another random compat package... No thanks.

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

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.

@MaximilianAlgehed

@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

@andreasabel

@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.

@MaximilianAlgehed

@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.

@andreasabel

@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.

@phadej

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)

@Bodigrim

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.

@MaximilianAlgehed

@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.

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.

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?

@sol

@sol:

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

This is a valid point.
But what about conditional dependencies, say only for old GHCs?

Say the goal was to provide a uniform API of QuickCheck across GHC versions, speaking now for the Solo instance, the dependency on OneTuple would only be needed when base < 4.16 meaning impl(ghc < 9.2).
That would not affect development versions of GHC nor MicroHs.

Maybe the issue here boils down whether these conditional dependencies are added to QuickCheck, implementing a uniform API and relieving the downstream user of coping with this problem. The current approach feels somewhat like a not my problem solution, pushing this downstream and thereby multiplying the problem, and potentially pushing it on a user base that does not have the technical insights for solving the problem effortlessly.

I wrote:

Why would I need QuickCheck-2.18 with an old compiler, why couldn't I use an older version of QuickCheck with them?

I remembered the answer to my own question. We want the latest version of a library even for old compilers when this version contains bug-fixes that are not backported to older versions of the library. Since backporting is infeasible in a resource-starved open-source community, the best practice is to make a new library version available to the widest user base as reasonably possible.

@MaximilianAlgehed wrote:

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.

Well, go to https://hackage-content.haskell.org/package/QuickCheck-2.18.0.0/docs/Test-QuickCheck.html#t:Arbitrary and scroll down to the Solo instance.

Where is the information that this instance is only available for certain GHC versions? I cannot even jump to the source code from here.
How can I know all the instances of Arbitrary are listed here, if it depends on which GHC was used to produce this page? It does to tell me which GHC was used to produce it in the first place, and certainly I would not expect that such would matter.

@andreasabel

On account of some behaviour in the community that @andreasabel has made us aware of we've decided to, bregudgingly, change our stance on this for the benefit of all. @andreasabel and @phadej can you provide me with a full list of these compat packages and affected types so that we can close this discussion?

When I was trying to use OneTuple I found it didn't work for mhs. See my attempts to make it work: haskellari/OneTuple#33

@phadej

Before we progress with this, @phadej and @andreasabel where is the official list of all the compat libraries that we need to support to keep quickcheck's API stable w.r.t. base versions incorporating specific older libraries?

I'd like to get this right w.r.t. this policy.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	#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

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

Description

Activity

MaximilianAlgehed commented on Jan 8, 2026

phadej commented on Jan 8, 2026

MaximilianAlgehed commented on Jan 8, 2026

andreasabel commented on Mar 4, 2026

MaximilianAlgehed commented on Mar 4, 2026

andreasabel commented on Mar 4, 2026

MaximilianAlgehed commented on Mar 4, 2026

Bodigrim commented on Mar 5, 2026

MaximilianAlgehed commented on Mar 5, 2026

andreasabel commented on Mar 5, 2026

MaximilianAlgehed commented on Mar 5, 2026

sol commented on Mar 5, 2026

andreasabel commented on Mar 6, 2026

MaximilianAlgehed commented on May 6, 2026

L0neGamer commented on May 6, 2026

MaximilianAlgehed commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions