|
Friends
Last month Simon M and I put forward a proposal to revise the process for developing the Core Haskell libraries: http://www.haskell.org/haskellwiki/Library_submissions/NewDraft There was some discussion, leading to improvements now incorporated in the draft, but I believe that there was general support; indeed no one opposed the change. Several weeks have gone by, so I suggest that we adopt the new process forthwith. Unless I hear otherwise I'll replace http://www.haskell.org/haskellwiki/Library_submissions with the new process in a day or two. We still need volunteers to become the maintainer of mtl random [though I think someone maybe did volunteer, Daniel perhaps?] Win32 Please! best wishes Simon _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
|
On Tuesday 07 June 2011, 23:42:41, Simon Peyton-Jones wrote:
> Friends > > Last month Simon M and I put forward a proposal to revise the process > for developing the Core Haskell libraries: > http://www.haskell.org/haskellwiki/Library_submissions/NewDraft > > There was some discussion, leading to improvements now incorporated in > the draft, but I believe that there was general support; indeed no one > opposed the change. > > Several weeks have gone by, so I suggest that we adopt the new process > forthwith. Unless I hear otherwise I'll replace > http://www.haskell.org/haskellwiki/Library_submissions > with the new process in a day or two. Great. > > We still need volunteers to become the maintainer of > mtl > random [though I think someone maybe did volunteer, Daniel perhaps?] Yes. I could also take over mtl, though I'd prefer to have a partner for that one. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
|
In reply to this post by Simon Peyton-Jones
I would be willing to pick up maintainership on mtl.
I already maintain its categorical dual after all, and it doesn't change all that often.
-Edward
On Tue, Jun 7, 2011 at 5:42 PM, Simon Peyton-Jones <[hidden email]> wrote: Friends _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
|
Great, thank you! mtl it is. Simon From: Edward Kmett [mailto:[hidden email]]
I would be willing to pick up maintainership on mtl. I already maintain its categorical dual after all, and it doesn't change all that often. -Edward On Tue, Jun 7, 2011 at 5:42 PM, Simon Peyton-Jones <[hidden email]> wrote: Friends _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
|
In reply to this post by Simon Peyton-Jones
Congrats on the award by the way – you have been winning my own superhero award but it’s cool to see some objective recognition. I had volunteered for random (and anything else you needed) – I thought you were being diplomatic (and maybe you were). Just made the major delivery on my contract so definitely feeling like some good works are in order… Cheers, Chris From: [hidden email] [mailto:[hidden email]] On Behalf Of Simon Peyton-Jones Friends No virus found in this message. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
|
Chris, Daniel, it looks like you both volunteered in this thread to be the "random" maintainer. Whoever it ends up being -- if you would like any backup I'd be happy to be listed as a co-maintainer. I have some interest in the topic because I was doing a bit of work recently on splittable RNG.
By the way, what is the feeling about using the FFI and foreign code in core libraries' implementations (aside from unix)? The reason I ask is that it would be nice to fix the statistical weakness in System.Random.split and I think the best way to do it is:
I did a prototype of this in http://hackage.haskell.org/package/intel-aes, and it seemed to have the potential to make a decent stdGen. First, this is because on the hardware I tested there was no performance regression relative to System.Random -- the portable, C, AES-based implementation performs a little better than the pure Haskell System.Random. Second, newer Intel and AMD machines have AESNI, which at least doubles the performance over the portable software version.
So it's a win for both performance and correctness; BUT there's more work to ensure portability across hardware and across Haskell implementations -- so does that tradeoff have any chance for a Core library?
-Ryan On Wed, Jun 8, 2011 at 4:14 AM, Chris Dornan <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
| Powered by Nabble | Edit this page |
