[m-rev.] time additions (was Re: for review: Add random.init/3)

Mark Brown mark at mercurylang.org
Sun May 29 06:39:50 AEST 2016

Hi Julien,

On Sat, May 28, 2016 at 3:15 PM, Julien Fischer <jfischer at opturion.com> wrote:
> On Sat, 28 May 2016, Mark Brown wrote:
>> On Sat, May 28, 2016 at 12:50 PM, Julien Fischer <jfischer at opturion.com>
>> wrote:
>>> To a large extent; the lack of support for constructor classes in the
>>> type class system has also meant that it isn't quite expressive enough
>>> to make their wholesale addition to the standard library worth it.
>> Providing an interface to random number generators is not a wholesale
>> addition, though. Is there any proposal for such an interface that
>> actually involves constructor classes? (Or is this more of an excuse
>> than a reason ;-))
> Ok, I wasn't terribly clear there :-(  What I meant is that the lack
> of type classes throughout the library _in general_ is largely due to
> the lack of constructor classes -- we cannot, for example, provide
> classes that abstract the various container types without them.
> In the specific case of a RNGs there is no problem with adding new
> classes (or indeed in any other case that doesn't require constructor
> classes).

That was clear enough, but I don't agree with the adverb "largely".
The problem I always seem to hit is the even older chestnut regarding
restrictions on the arguments of typeclass instances. Sometimes you
can work around these, but often that's where I get stuck.

IIRC, you removed some of these restrictions a few years ago, but I
don't remember the details. The remaining restrictions are still a
problem, though.

On Sat, May 28, 2016 at 12:50 PM, Julien Fischer <jfischer at opturion.com> wrote:
> This kind of thing has been discussed several times in the past
> (see:
> <http://lists.mercurylang.org/archives/users/2007-February/004331.html>
> for example.)

I don't like these proposals. As Doug Auclair pointed out, the method
to seed the generator doesn't belong together with the method to
generate numbers, because you usually don't use these methods in the
same parts of the program. Exactly how a generator is initialised
depends very much on the generator - some generators don't even have
seeds (e.g., one that reads from a file).

I also don't like putting the burden of managing the precision of the
generators on the caller, by having a method like max/3. It's better
to have those generators that need such management to handle it in
their own way, and require all generators to produce a full word of
random bits.

As an aside, note that the tausworthe3 generator mentioned (which I
think is the one from extras/gator) fails almost all of the dieharder
tests on 64-bit platforms, which is a slight bug. Looking at the code,
it seems that 64-bit platforms would need to truncate values to 32
bits after some of the left-shift operations, since this is what would
happen on on a 32-bit platform.

> My current thinking on this is that all random number generators should
> be required to have a unique state value threaded through their
> operations.

Agreed. Even when generators don't actually need the uniqueness, it's
good to stop users accidentally copying a generator when they don't
mean to. Making it unique will force them to explicitly duplicate a
generator if that's what they want to do.

> That value would be required to be an instance of the
> standard library's store/1 type class

It would certainly be very nice to do this. But here's what happens when I try:

    % Random number generator G with store S
:- typeclass random(G, S) where [
    pred random(G::in, int::out, S::di, S::uo) is det

    % This is the instance I want to write.
:- instance random(generic_mutvar(T, S), S) <= store(S).

But it's not accepted because the second argument is a variable.

I could instead try something like:

:- instance random(io_mutvar(T), io) where ...
:- instance random(store_mutvar(T, S), store(S)) where ...

But these can't be used in code which is already generic in the store
that is being threaded through. You need to write the same code out
twice, too.

Anyone have any ideas?

> (i.e. the current RNG interface,
> such as it is, would be pretty much entirely thrown away).

No objections from me.

Does your earlier removal of some of the restrictions help with any of
the above?


More information about the reviews mailing list