Generic default definition for UniformRange

[Bodigrim]

This is a first cut, need to avoid recursive calls in instance GFiniteRange (a :+: b) and add tests.

Here is an example:

>>> :set -XDeriveGeneric -XDeriveAnyClass
>>> import GHC.Generics (Generic)
>>> import Data.Word (Word8)
>>> import System.Random.Stateful
>>> gen <- newIOGenM (mkStdGen 42)
>>> data Tuple = Tuple Bool Word8 deriving (Show, Generic, Finite, FiniteRange, Uniform, UniformRange)
>>> Control.Monad.replicateM 10 (uniformRM (Tuple False 100, Tuple True 150) gen)
[Tuple False 127,Tuple True 130,Tuple False 113,Tuple False 150,Tuple False 125,Tuple True 124,Tuple False 110,Tuple True 132,Tuple False 116,Tuple True 136]
>>> data Foo = Bar Word8 | Quux Word8 deriving (Show, Generic, Finite, FiniteRange, Uniform, UniformRange)
>>> Control.Monad.replicateM 10 (uniformRM (Bar 100, Quux 150) gen)
[Bar 119,Quux 92,Quux 51,Bar 124,Quux 65,Bar 239,Bar 140,Bar 230,Quux 59,Bar 210]

[Bodigrim]

All right, this is ready for review now.

[Shimuuar]

What really bothers me is generic instance for sum types. It uses completely different logic from product case. Generic instances for some class Foo are mostly used to build instances from Foo instances of data type's fields. I think such instance would be very surprising for users.

Also I don't think it's very useful I can't imagine any use case where I'd want such instance (it may be lack of imagination, though). It would be better to define no default instances for sums and provide functions to define UniformRange in terms of FiniteRange

[Bodigrim]

Also I don't think it's very useful I can't imagine any use case where I'd want such instance (it may be lack of imagination, though).

It is most useful and meaningful to derive instance UniformRange for simple enumeration types like data DayOfWeek = Monday | ... | Sunday. And I can easily imagine some kind of payload attached to enums (e. g., types isomorphic to Maybe or Either).

The proposed deriving strategy mirrors the existing one for Uniform and has a nice property of always producing a lawful instance UniformRange. Of course, if your data is not simply a sum of products, but has some internal invariants, this could be not exactly what you want, but in this case you should not rely on Generic instances anyways.

It would be interesting to look at a finitely-inhabited data type, for which one would like to have a different instance than produced by Generic. Do you possibly have an example in mind?

[Shimuuar]

Laws are very lax and for any single allow many lawful instances. Lawful alone is not enough instance should be meaningful as well. For range it's simple: derived instance is product of ranges. But what is instance for data Foo = F1 Int Int | F2 Char? random will derive something without even blinking. I think in practice it'll lead to creation of rule: "random will crate weird instance for sum types, never do that except for enum-like types". Footgun essentially.

Real problem is I think that we have single strategy: generics (deriving via couldn't be used because of polymorphic m).And we're trying to squeeze everything into into it. Maybe it's better to limit generic deriving sums to enum-like types?

Another possibility to provide default implementations using Enum etc. Instance will become more verbose but at least it'll be clear what is going on

instance UniformRange DayOfWeek where
  uniformRM = defaultUniformRMviaEnum
  isInRange = defaultIsInRangeviaEnum

[Bodigrim]

I think in practice it'll lead to creation of rule: "random will crate weird instance for sum types, never do that except for enum-like types".

I do not want to argue right now. I removed UniformRange instances for sum types to make it less debatable. I believe it's important to get UniformRange at least for product types, including tuples.

[Shimuuar]

LGTM. I do think that proposed default instance for sum types is ill advised. Product types on the contrary are quite reasonable.

[idontgetoutmuch]

I still worry about this even though it's not a change since we had isInRange with the same definition so the boat has sailed. BTW what do we get with isInRange (127 :: Int8, -128 :: Int8) - it seems

> fst $ (uniformR (127 :: Int8, -128)) (mkStdGen 42)
fst $ (uniformR (127 :: Int8, -128)) (mkStdGen 42)
-80

I would have expected 127 or -128 as I think of Int8 as a clock - perhaps I shouldn't. Anyhow nothing to do with this change.

[lehins]

@idontgetoutmuch I don't think you need to worry about it. Your clock or modulo arithmetic thinking is not really valid here. Especially since it would not work universally for all types. For example what would you suggest the behavior to be on: fst $ (uniformR (127 :: Double, -128)) (mkStdGen 42)?

I think our approach is a perfectly acceptable. We have the law documented:

uniformR (a, b) = uniformR (b, a)

Without that law we cannot make uniformR a total function.

[idontgetoutmuch]

LGTM