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

[Sebastian Godelet]

Hi Julien,

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?

> 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.
Or can I assume that Mercury supports at least ISO C99?
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)

> 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?

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.

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

> 
> > 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?

cheers,

Sebastian.