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