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

[Julien Fischer]

Hi,

On Fri, 27 May 2016, Sebastian Godelet wrote:

> Actually I must have done something wrong during recompilation (wrong
> PATH I guess), I could reproduce the same problem you got, sorry for
> the false
>
> % Linking...
> % Invoking system command `ar @C:\msys64\tmp\mtmp0023C8'...
> ar: C:\msys64\tmp\0023C6.a: File format not recognized
>
> Maybe something with the prefix calculation went wrong?

Yes, that's what I have been seeeing. I don't think it's anything from a
recent change since I tried out an ROTD from January and that appears to
have the same problem.

>> I've written a library that does this (<https://github.com/juliensf/mercury-
>> inttypes>)
>> for the C, C# and Java backends.  However, the lack of literals for each
>> type of integer does make using it a bit fiddly.
>>
>
> Actually I'd already be happy if configure would not only search for
> MR_int_least32, but also the exact types, like int32_t and so on.

I will look into adding them.

> Or can I assume that Mercury supports at least ISO C99?

No, you may not (yet) assume that.  Versions of Visual C++ prior to about 2012
don't provide stdint.h.  (We could of course drop support for those
versions, but I don't like dropping support for older C compilers unless
it is absolutely necessary.)

> But yeah literal support would of course also greatly simplify things,
> not just for this use-case, e.g. the C++11 approach of a flexible
> suffix system (great for unit calculation)

I wouldn't necessarily advocate the C++ approach of allowing users to define
there own though.

>> The ultimate problem here is that Mercury's current random and time
>> modules are simply not very good.  For random, what the standard library
>> *should* be providing is a generic interface to random number generators
>> in general (e.g. something along the lines of Boost.Random, but using
>> type classes), along with some actual instances of generators.
>
> Yes if I understood correctly typeclasses are not used that much in
> the standard library since they pre-date it, right?

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.

> I would have trouble to define a typeclass which supports non-IO
> threaded and IO threaded random numbers at the same time, i.e. a PRNG
> which just relies on pure integer calculation does not need IO state
> threading, but a cryptographically one does.

There are plenty of cryptographically secure RNGs that would not require
the I/O state to be threaded through them.

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.)

My current thinking on this is that all random number generators should
be required to have a unique state value threaded through their
operations.  That value would be required to be an instance of the
standard library's store/1 type class (i.e. the current RNG interface,
such as it is, would be pretty much entirely thrown away).

>> I find the current time module a bit too C-like, also it's not terribly well
>> integrated with the calander module.
>
> Yes at its current state it is not very useful for non-C backends.
> Here Java 6 might be an obstacle again, since that old Date interface
> is deprecated.

I would like to bump the minimum Java version we support, however
there's still a lot of Java 6-only code out there in the "real world".
(And as I happen to need to support one of them, this won't be changing
any time soon ...)

>>
>>> Not sure about the IO threading though
>>
>> You'll need it if you want to maintain purity -- on my system
>> (OS X) /dev/random is backed by an entropy pool that is refreshed
>> every so often by the OS, that's very much an I/O operation.
>> (See 'man 4 random' on OS X for details.)
>
> Does OS X also support /dev/urandom?

On OS X, it's an alias for /dev/random.  'man 4 random' says:

      /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom
      will produce lower quality output if the entropy pool drains, while
      /dev/random will prefer to block and wait for additional entropy to
      be collected.  With Yarrow, this choice and distinction is not
      necessary, and the two devices behave identically. You may use either.

Julien.