search

idontgetoutmuch / random

Random number library
Other
3 stars 2 forks source link

Build QuickCheck with random v1.2 #50

Open curiousleo opened 4 years ago

curiousleo commented 4 years ago

I'm going to use this ticket to report my findings trying to port QuickCheck to random v1.2.

QuickCheck goes to some lengths to be Hugs-compatible. Currently it uses SplitMix' SMGen on GHC and StdGen from random v1.1 on Hugs. That's an issue: I assume this is done because SplitMix does not build on Hugs. As a consequence, random v1.2 won't build on Hugs either, so its StdGen cannot be used as a fallback on non-GHC compilers by QuickCheck.

A: SplitMix does not build on Hugs.

primitive and bytestring are GHC-only. MutGen is based on MutableByteArray from primitive, and the genByteArray default implementation is also based on stuff imported from primitive. If we want to, I believe that we can get random v1.2 to compile without primitive and bytestring by putting MutGen and the genByteArray default implementation behind a flag.

A: Yes, we can build random v1.2 without bytestring and primitive with CPP.

splitmix depends on deepseq, which is GHC-only. We could probably copy the actual PRNG code into random v1.2 and make it work without deepseq.

lehins commented 4 years ago

I think QuickCheck can use the old version of random-1.1 for hugs compiler if they wanna stay compatible. If I understand it correctly the only reason why QuckCheck supports hugs is because it has been around since when Hugs was a thing.

Hugs is pretty much dead, so I don't think it is something we need to concern our selves with.

So the question should be: Are there any other Haskell compilers other than GHC we should support?

I personally think there is no compelling reason for adding more complexity in order to support esoteric compilers. It is better to provide functionality for efficient creation of a chunk in memory filled with random data.

Adding flags and CPP should be our last resort and I don't think that is a good enough reason for that. @curiousleo even your boss says that CPP is harmful :D

I would rather spent more time into making older versions of ghc supported rather than wasting time on Haskell compilers that we aren't even planning on testing random with. It makes more sense for users of other compilers to contribute compatibility functionality instead of us trying to guess what works and what doesn't.

curiousleo commented 4 years ago

@lehins I think I agree. There is a problem though: if a project depends on random v1.2 and uses QuickCheck for its tests, building the tests will fail.

Example:

In the dependencies for QuickCheck-2.13.2:
    random-1.2 from stack configuration does not match >=1.0.1.0 && <1.2  (latest matching version is 1.1)

allow-newer: True in stack.yml circumvents this for now (since random v1.2 is mostly backwards-compatible), but I'm not sure if that is a satisfactory solution to recommend to people.

Edit: perhaps hedgehog is easier to port to random v1.2? In that case we could recommend its use for libraries that build upon random v1.2. I'll investigate this in a separate issue.

Edit 2: relevant recent overview of property testing libraries: https://youtu.be/x-zxvTkapcU?t=337

lehins commented 4 years ago

I don't really see a problem here. Bounds will have to be relaxed in QuickCheck. I don't think we introduced any changes that would break QuickCheck.

There is a problem though: if a project depends on random v1.2 and uses QuickCheck for its tests, building the tests will fail.

I was in the audience. :) Syd gave this talk here in Minsk

relevant recent overview of property testing libraries: https://youtu.be/x-zxvTkapcU?t=337

curiousleo commented 4 years ago

I don't really see a problem here. Bounds will have to be relaxed in QuickCheck. I don't think we introduced any changes that would break QuickCheck.

We did, in a sense: QuickCheck used to rely on StdGen from random v1.1 for its Hugs / UHC / non-GHC build. They will not be able to upgrade to random v1.2 because that would break their build on non-GHC systems.

Or is what you're saying that if a project's library/application code uses random v1.2 then it's clearly a GHC project, in which case they can also force the QuickCheck dependency in their tests to build against random v1.2 because clearly they don't care about compatibility with compilers other than GHC in the first place? I can see that argument working.

I was in the audience. :) Syd gave this talk here in Minsk

Nice :)