[m-rev.] time additions (was Re: for review: Add random.init/3)
sebastian.godelet at outlook.com
Fri May 27 22:29:52 AEST 2016
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
% 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-
> 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?
More information about the reviews