On Tuesday, 8 January 2013 at 20:40:00 UTC, H. S. Teoh wrote:
On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton
Wakeling wrote:
On 01/08/2013 07:38 PM, ixid wrote:
>I imagine there has been some detailed discussion of the
>std.nameX
>idea of libraries so forgive me if this has been discussed.
I appreciate your concern on this point, but I don't think
it's the
right thing to focus on in this specific discussion.
What I really want address is: how do we get the design of
std.random
_right_?
How we go about incorporating that new design into Phobos with
minimal hassle for users is a different issue and one we can
face
when the time comes.
For one thing, I'd say definitely make RNGs have reference
semantics.
Passing by value just doesn't make sense; for large generators
it
consumes too much stack space and risks stack overflow, and in
any case
copying RNGs unintentionally causes duplicated sequences, which
is very
bad.
For those cases where you *want* to copy an RNG, it should be
made into
a forward range and then you use .save explicitly.
I'd argue PRNG's should even be forward ranges. For one, the
actual saving would be duplicating the PRNG payload itself (very
costly). Further more, it would mean the danger of duplicate
sequence still exist: a lot of algorithms, such a "fill", start
by saving their input, and then iterating on the copy...
I'm all for them having "dup" though.
Worst case scenario, I had written an adaptor that turns a
InputRangePRNG into a ForwardRangePRNG, but this is at the
*explicit* request of the *user*, and not by any underlying
algorithm.
And even then, I'd *still* advise against using this adaptor. If
you *must* store and iterate on random values several time, just
copy them in an array doing prng.take(N).array(). Clean,
efficient, safe.
@jmdavis was against making them input ranges, saying input
ranges just aren't useful compared to a forward range. I think
that:
1. A PRNG naturally models input, and not forward.
2. Algorithms that operate on actual random sequenes shouldn't
rely on the PRNG to be saveable anyways: A *true* RNG simply
cannot provide save.
I wonder if it even makes sense to force RNGs to inherit from a
common
base class, so that reference semantics are enforced even for
user-defined types. But this may be a bit too heavy-handed (and
it will
alienate the no-GC crowd).
Force: No. However, we *can* provide tools to help with the
operation though.
Since the recommended implementation of a PRNG is "pointer to
payload", I had written an adapter template which took a "Stack
payload implementation" and turned it into a reference semantic
type. This meant I pretty much transformed all our PRNGs into
reference ranges, without even touching any of their
implementations.
If a user doesn't want it, fine.
