
Ben, We invited anyone interested including Carter to participate in the design back in February. He did not do so. How much longer do you think we should give him? No serious work has been done on it since September 2014 and numerous promises to do something have never materialised. Is there any part of Carter’s critique that in your view has not been addressed by replies in this thread? We should be welcoming contributions and improve libraries when the opportunities arise and not wait another 5 years for perfection (which may never arrive). Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch
Message: 4 Date: Wed, 3 Jun 2020 13:11:08 +0200 From: Ben Franksen
To: libraries@haskell.org Subject: Re: Improving Random Message-ID: Content-Type: text/plain; charset=utf-8 I agree that communication is an important aspect of maintainership. Not responding to PRs for a long period of time is bad because it lets people wonder if anything is being done about it at all. That can be quite frustrating as I know from my own experience.
That said, Carter's critique of the proposed API (the classes) looks valid to me. I understand that coming up with a better API design that accommodates all the cool permormance improvements may take its time.
@Carter: why don't you try to eleborate your critique of the proposed API on the tracker and present a rough sketch of where you think things should go instead. Then you guys can all work together to flesh this out.
My experience is that writing things down helps a lot to get them clearer in my head. If the side effect is people feel that their contributions are respected and actually worked on, so much the better.
Cheers Ben
------------------------------
Subject: Digest Footer
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
------------------------------
End of Libraries Digest, Vol 202, Issue 4 *****************************************

Am 03.06.20 um 15:55 schrieb dominic@steinitz.org:
We invited anyone interested including Carter to participate in the design back in February. He did not do so. How much longer do you think we should give him?
Two weeks, perhaps four?
No serious work has been done on it since September 2014 and numerous promises to do something have never materialised.
I can't possibly comment on this.
Is there any part of Carter’s critique that in your view has not been addressed by replies in this thread?
He wrote
The *better* choice is Class PRNG g => MonadRandom m g | m-> g where ...
And then their example instance should be something like
Newtype MWCT m a = ... newtype wrapper around StateT m a threading an MWC indexed by the state token of the underlying PrimMonad (Or newtype MWCT s m a = .... stateT thing)
Instance (PrimMonad m) => MonadRandom (MWCT m) (MCWGen (PrimState m)) where ...
We should be welcoming contributions and improve libraries when the opportunities arise and not wait another 5 years for perfection (which may never arrive). I can understand that you don't want this to stall indefinitely, so
which hasn't been addressed fully. However, this would be difficult since the above comment is missing too many details. This is why I wanted to entice Carter to share his thoughts/misgivings/counter-proposals in greater detail on the PR. perhaps you need to give him a (comfortable) deadline? Just a thought. Cheers Ben

Hey Ben,
Two weeks, perhaps four?
Already 3 weeks has passed since the proposal has been submitted. If Carter said "Give me two weeks and I'll have a release ready", I personally would not believe it, but at least it could have been considered a concrete deadline. Instead we got "I am taking my time with it".
Class PRNG g => MonadRandom m g | m-> g where
What Carter suggested, I believe, would only complicate things. FunctionalDependencies in definition means that for every generator you need to create your own monad, which will have to also be a monad transformer for some generators, so you'd have to worry about all these instance and the user would have to worry about yet another monad transformer. What we currently have in the proposal does not require any special new data types or new monads being created. Existing stateful generators can just create an instance for any monad they suppose to work in, notable ones are `ST`, `IO` and of course all monads that have `PrimMonad` instance.
This is what we have now:
class Monad m => MonadRandom m g where
which means stateful generators can create:
instance (s ~ PrimState m, PrimMonad m) => MonadRandom (MWC.Gen s) m where -- mwc-random package
instance (s ~ PrimState m, PrimMonad m) => MonadRandom (PCG.Gen s) m where -- pcg-random package
instance (s ~ PrimState m, PrimMonad m) => MonadRandom (SFMT.Gen s) m where -- sfmt package
instance MonadRandom MTGen IO where -- mersene-random package
and every pure generator that has `RandomGen` instance can be used with any monad that has `MonadState` instance:
instance (RandomGen g, MonadState g m) => MonadRandom (StateGenM g) m where
These instances cover all of pure and stateful non-crypto RNGs available in Haskell, which can be used with any monad transformer (through PrimMonad and MonadState instances). There are also wrappers around IORef and STRef for pure generators that can be used in IO and ST respectfully, but that is a minor detail.
Hopefully I now addressed that comment for you, because Carter does not seem to be interested in this, since he locked PR I opened and it is now a one directional communication.
Alexey.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 3, 2020 9:31 PM, Ben Franksen
Am 03.06.20 um 15:55 schrieb dominic@steinitz.org:
We invited anyone interested including Carter to participate in the design back in February. He did not do so. How much longer do you think we should give him?
Two weeks, perhaps four?
No serious work has been done on it since September 2014 and numerous promises to do something have never materialised.
I can't possibly comment on this.
Is there any part of Carter’s critique that in your view has not been addressed by replies in this thread?
He wrote
The better choice is Class PRNG g => MonadRandom m g | m-> g where ... And then their example instance should be something like Newtype MWCT m a = ... newtype wrapper around StateT m a threading an MWC indexed by the state token of the underlying PrimMonad (Or newtype MWCT s m a = .... stateT thing) Instance (PrimMonad m) => MonadRandom (MWCT m) (MCWGen (PrimState m)) where ...
which hasn't been addressed fully. However, this would be difficult since the above comment is missing too many details.
This is why I wanted to entice Carter to share his thoughts/misgivings/counter-proposals in greater detail on the PR.
We should be welcoming contributions and improve libraries when the opportunities arise and not wait another 5 years for perfection (which may never arrive).
I can understand that you don't want this to stall indefinitely, so perhaps you need to give him a (comfortable) deadline? Just a thought.
Cheers Ben
Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

(I certainly don't want to pile on, just want to emphasize a really important point which I've learned over the years shipping lots of software... which, while not perfect in any way, has certainly worked "well enough") On 03/06/2020 15.55, dominic@steinitz.org wrote:
not wait another 5 years for perfection (which may never arrive).
Aka. "perfect is the enemy of good". Unless it can be shown that these changes to the 'random' library *actively* prevent any later improvements[0], I'd say that this aphorism applies rather... good. [0] Specific suggestions would be necessary for credibility. Regards,
participants (4)
-
Alexey Kuleshevich
-
Bardur Arantsson
-
Ben Franksen
-
dominic@steinitz.org