On 5/23/2014 3:04 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
Hi Nick,
Short reply because I think things are converging pretty well
decision-wise :-)
because crypto RNGs' .popFront() is of necessity going to be non-pure.)
To make sure I understand (it seems my understanding of D's pure isn't
quite as
strong as I'd thought): It cannot be pure *because* of the static
internal
state, right?
The main issue is because your popFront will be relying on external
sources of entropy which I presume to be non-deterministic (otherwise,
what entropy are they adding?). That's what makes purity impossible.
As we've discussed, you could avoid having the static variables, but as
the function is going to be impure anyway, they shouldn't be avoided
over the purity issue.
Oh, right. For some reason I was thinking "front", not "popFront". My bad.
I think I may have missed that particular discussion (I've only been
catching
the livestreams of certain talks). Recap?
Andrei's opening keynote seemed pretty clear that we need a space in the
standard library where people can experiment freely. He called it
std.experimental but I suspect the name will be something different :-)
Didn't we already have exp.* for that? (Or something like that.)
That's one talk I sadly missed. Anxiously awaiting the rerun on YouTube.
Well, what I'm inclined to do is to submit my Phobos package as an
experimental module (probably call it exp.random or something like
that). I can and probably will do that in the very near future.
I think that you should similarly feel unrestricted, but maybe give it a
day or two post-Dconf to see what the actual plan is about the
experimental repo.
Ok.
By the way, what are your thoughts on having a std.random.crypto module
versus a general std.crypto module that includes crypto RNGs and other
crypto functionality? I'd been considering a std.random.crypto but I'm
starting to incline towards the view that std.random and crypto should
be kept deliberately separate.
Well, I don't think crypto RNGs should be put together with non-RNG
crypto stuff like SHA, etc. (Unless maybe it's all under a
"std.crypto.*" package...but then you still have weird questions like
"Does MD5 go in std.digest.md or std.crypto.digest.md? What about
SHA-1?" So still maybe kinda hairy.)
As for whether crypto RNGs should be together with non-crypto RNGs, I
dunno. I can't really say I'd have much objection either way. I suppose
there is general preference in D at this point to break up phobos
modules wherever reasonable, so I guess something like this might
generally be preferred:
std/random/package.d
std/random/deterministic.d
std/random/crypto.d
But I don't have any strong opinions on the matter. I'd say just pick
something, run with it, and see if any bikeshedding erupts ;)
