www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Convert std.random to a package

reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
Hello all,

As I promised at DConf (though sadly arriving a bit later than 
I'd hoped), I've submitted a PR to convert std.random to a 
package:
https://github.com/D-Programming-Language/phobos/pull/3406

I'd like to ask for some attention to this because, first, I 
think it's important that we agree that this particular package 
structure is correct/logical, and second, I really don't want to 
have to rework this if anyone commits to std.random in the 
meanwhile ;-)

Beyond perhaps documentation issues I hope this PR should be 
fairly non-controversial and easy to approve (or disapprove).

Thanks & best wishes,

      -- Joe
Jun 24 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 24 June 2015 at 12:15:10 UTC, Joseph Rushton 
Wakeling wrote:
 Hello all,

 As I promised at DConf (though sadly arriving a bit later than 
 I'd hoped), I've submitted a PR to convert std.random to a 
 package:
 https://github.com/D-Programming-Language/phobos/pull/3406

 I'd like to ask for some attention to this because, first, I 
 think it's important that we agree that this particular package 
 structure is correct/logical, and second, I really don't want 
 to have to rework this if anyone commits to std.random in the 
 meanwhile ;-)

 Beyond perhaps documentation issues I hope this PR should be 
 fairly non-controversial and easy to approve (or disapprove).
Is there any point in doing this if we're going to be redesigning std.random as you've been working on? In fact, it could get in the way of that, since we could potentially just make the new version be modules in the package, and the old version be in std.random.package (meaning that if you imported std.random, you get the old, deprecated stuff, and if you import std.random.foo, you get the new stuff). - Jonathan M Davis
Jun 24 2015
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 24 June 2015 at 14:16:04 UTC, Jonathan M Davis 
wrote:
 Is there any point in doing this if we're going to be 
 redesigning std.random as you've been working on? In fact, it 
 could get in the way of that, since we could potentially just 
 make the new version be modules in the package, and the old 
 version be in std.random.package (meaning that if you imported 
 std.random, you get the old, deprecated stuff, and if you 
 import std.random.foo, you get the new stuff).
Interesting point. My own impression, based on discussions at DConf, was that it ought to be possible to proceed to "good" RNG solutions via a deprecation path from existing functionality, by things like deprecating (and then disabling) implicit copy, and so on. That would avoid any need for maintaining old and new side by side. However, it might be worth taking the approach you suggest -- developing new stuff in parallel, deprecating old stuff, and finally removing the old std.random functionality entirely in favour of public import of the new stuff. I certainly don't mind putting this on the back burner until "what a proper solution looks like" is ironed out.
Jun 24 2015
parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Wednesday, 24 June 2015 at 14:28:52 UTC, Joseph Rushton 
Wakeling wrote:
 On Wednesday, 24 June 2015 at 14:16:04 UTC, Jonathan M Davis

 I certainly don't mind putting this on the back burner until 
 "what a proper solution looks like" is ironed out.
I'm sympathetic to this approach. I wouldn't get too far ahead of yourself though. The easier it is for people to switch to your new approach the better (which seems interesting, I loved your DConf talk). It seems like you are focused on the core random number generators at the moment. I don't have much experience working on them, but I do with statistics and statistical packages more generally. Some language's statistical support is better organized than others. For instance, python has numpy.random and scipy.stats and both of them can generate random variables from a variety of different distributions. scipy.stats by itself isn't that bad, I suppose. It has a similar set-up as Julia's Distributions.jl. They're both more than just random number generators, allowing a variety of functions (pdfs, cdfs, etc). It seems like they both take a class approach using a lot of inheritance.
Jun 24 2015
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 24 June 2015 at 17:34:59 UTC, jmh530 wrote:
 I'm sympathetic to this approach. I wouldn't get too far ahead 
 of yourself though. The easier it is for people to switch to 
 your new approach the better (which seems interesting, I loved 
 your DConf talk).
Thank you! :-) To all: sorry for the slow response here. It's turned out to be one of those weeks/months. I'll try and follow up some time soon with an outline of the ideas that sprang from DConf suggestions by Steve S., Dicebot and others.
Jun 30 2015
prev sibling parent "HaraldZealot" <harald_zealot tut.by> writes:
On Wednesday, 24 June 2015 at 14:16:04 UTC, Jonathan M Davis 
wrote:
 On Wednesday, 24 June 2015 at 12:15:10 UTC, Joseph Rushton 
 Wakeling wrote:
 Hello all,

 As I promised at DConf (though sadly arriving a bit later than 
 I'd hoped), I've submitted a PR to convert std.random to a 
 package:
 https://github.com/D-Programming-Language/phobos/pull/3406

 I'd like to ask for some attention to this because, first, I 
 think it's important that we agree that this particular 
 package structure is correct/logical, and second, I really 
 don't want to have to rework this if anyone commits to 
 std.random in the meanwhile ;-)

 Beyond perhaps documentation issues I hope this PR should be 
 fairly non-controversial and easy to approve (or disapprove).
Is there any point in doing this if we're going to be redesigning std.random as you've been working on? In fact, it could get in the way of that, since we could potentially just make the new version be modules in the package, and the old version be in std.random.package (meaning that if you imported std.random, you get the old, deprecated stuff, and if you import std.random.foo, you get the new stuff). - Jonathan M Davis
Please not such way. Idea with package 'experimental' and 'deprecated' looks like more preferable. (This idea was discussed in std.container fork. For example new random API go to std.experimental.random all old API remain in std.random, when stable state of new API was approved that renaming happens: std.random -> std.deprecated.random and in next DMD/Phobos release std.experimental.random -> std.random. Also were good provide with new release tool that autofix stuff like this)
Jul 01 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/24/2015 08:15 AM, Joseph Rushton Wakeling wrote:
 Hello all,

 As I promised at DConf (though sadly arriving a bit later than I'd
 hoped), I've submitted a PR to convert std.random to a package:
 https://github.com/D-Programming-Language/phobos/pull/3406
If we're converting more modules to packages, then it's all the more important this issue finally get fixed, because it's a big gaping hole in the whole "package.d is for doing this *without* breaking user code" thing: https://issues.dlang.org/show_bug.cgi?id=11847
Jun 24 2015