I’ll try and address the points. 1. I proposed a low cost solution as advocated by Sven and Henrik about 2 years ago, that of using tf-random. This was rejected because apparently better RNGs might exist. Now as we all know there is no such thing as the best RNG. My reasoning for tf-random was that if it were good enough for QuickCheck then it would certainly be good enough for naive users. A case of the best driving out the good? Not that best exists in this case. 2. QuickCheck were bitten very hard! 3.

Prelude> import System.Random Prelude System.Random> let dieRoll = fst . randomR (1,6) . mkStdGen :: Int -> Int Prelude System.Random> map dieRoll [1..20] [6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6]

4. In addition to the problems adumbrated above, random also has a range

Prelude System.Random> newStdGen >>= return . genRange (1,2147483562)

which makes it fail even testu01’s SmallCrush if used naively. random *may* work in certain cases but I would strongly advise against using it when there are so many other packages without the above problems. I would also add that for e.g. MCMC it is often very hard to see if something is working or not working because of the Monte Carlo noise; something apparently working does not necessarily validate a particular RNG. I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action. Anyhow as I have already said I feel I have done my bit for the Haskell Community. I agree with Carter that this is out of scope for the Core Libraries Committee. I wish you all luck and will step down from being maintainer.

On 25 Jan 2017, at 11:26, libraries-request@haskell.org mailto:libraries-request@haskell.org wrote:

Send Libraries mailing list submissions to libraries@haskell.org mailto:libraries@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to libraries-request@haskell.org mailto:libraries-request@haskell.org

You can reach the person managing the list at libraries-owner@haskell.org mailto:libraries-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."

Today's Topics:

1. Re: Selection Monad (Jakub Daniel) 2. Add Zero and One to Data.Functor (mirroring V1, U1) (Baldur Blöndal) 3. Re: Random Number Update (Sven Panne) 4. Re: Random Number Update (Henning Thielemann) 5. Re: Random Number Update (Andreas Abel) 6. Re: Random Number Update (Henrik Nilsson)

----------------------------------------------------------------------

Message: 1 Date: Tue, 24 Jan 2017 17:23:58 +0000 From: Jakub Daniel mailto:jakub.daniel@gmail.com> To: Eric Mertens mailto:emertens@gmail.com> Cc: libraries@haskell.org mailto:libraries@haskell.org Subject: Re: Selection Monad Message-ID: mailto:CACaCNTSj5T0GnGkWgk_VO8vaL4dZYao16QUTCvYMXvsAyUw1oQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"

Hi Eric,

Just to clarify, my question was not about endorsing another library but rather extending the ones currently maintained by the committee with definition of a notion closely related to what is already contained in the libraries. It just so happens that Edward Kmett implemented the notion in a standalone library. However to me it does not make much sense to include ContT but not SelT (currently under the name Search) in the core libraries, despite their connection. I understand if this does not change the answer though.

Best Regards, Jakub Daniel

On Tue, 24 Jan 2017 at 17:39 Eric Mertens mailto:emertens@gmail.com> wrote:

...

Hi Jakub,

The core libraries committee helps maintain libraries that are already critical to the Haskell ecosystem. It doesn’t select new libraries to be recommended to users. It’s possible that the search package is a hidden gem that more people need to know about. To accomplish that people will need to write software using it, market it with blog posts, and bring it up in discussions.

Best Regards, Eric Mertens

On Jan 24, 2017, at 5:57 AM, Jakub Daniel mailto:jakub.daniel@gmail.com> wrote:

Hello,

I apologize in case this is not the right place to bring this question/proposal up. Some time ago I stumbled upon the Selection Monad [1] (also referred to as Search from the search package on hackage). Its relation to the Continuation Monad and the usefulness demonstrated in [1] made me wonder whether it would be nice to include Selection Monad in the core libraries along the Continuation Monad (in mtl and transformers) with all the business of selections attaining continuations. I can imagine the pattern to be too little recognised to justify such an addition, yet the theoretical connection to the Continuation Monad seems to be an interesting one and worth being addressed.

Best,

Jakub Daniel

[1] Jules Hedges. *Monad transformers for backtracking search*. In *Proceedings of MSFP 2014. *https://arxiv.org/abs/1406.2058 https://arxiv.org/abs/1406.2058

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries