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

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

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.

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

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.

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.

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)