2009/2/5 Peter Verswyvelen :

Of course you could just put this random generator in the IO monad, but certain algorithms- like Monte Carlo - intuitively don't seem to operate in a IO monad to me.

For PRNGs, only State is needed, not IO. But you might find the `randoms' function useful: it returns in infinite list of pseudo-random values. --Max

Well, one could say that a truly random number function takes as input time and some constant unique identifier (serial number) of the TRND device and gives you the random value measured at that time by this device. Of course this would mean the random value is not really random, since "the potential creator of the universe" would have known the value already, but to all humble beings living in the bubble, it would be Truly Random :) Then the question is, is time a function? If so, is it discrete? Okay, this is not Haskell anymore, this would become philosophy, and since a good and smart friend of mine told me that nobody really knows what time is, this is off topic. Sorry! :) On Thu, Feb 5, 2009 at 11:31 PM, Jake McArthur wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Peter Verswyvelen wrote: | I do have asked myself the question whether a "really random generating" | function could be regarded as "pure" somehow (actually would a true | random function still be a mathematical function?) | | E.g. the function would return a true (not pseudo) random number, | practically unpredictable (e.g. hardware assisted, using some physical | phenomenon, e.g. using atmospheric noise or something). So you surely | won't get referential transparency but since the function is really | random, this would be correct behavior?

An informal definition of a function might be something like a black box that takes and input and produces an output, and for each possible input, the output must be the same. Taking this to be a function, there is really no such thing as a random function, and if there was, it wouldn't even need to be a function. (What would the input to it be?)

If you wanted to mathematically represent a random number, it would, in most cases I can think of, best be represented as a free variable. In a program, such a free variable could be filled in by the runtime. Conveniently, (and by no coincidence) this is something the IO monad can provide for us! :)

| Of course you could just put this random generator in the IO monad, but | certain algorithms- like Monte Carlo - intuitively don't seem to operate | in a IO monad to me.

Why not?

A Random monad might be more appropriate in this case anyway. Such a monad is a State monad that hold a random seed. Every time a random number is needed, the seed is passed to a deterministic psuedo-random number generator, and a new seed is put as the next state.

If a truly random number is ever needed, either IO or unsafeInterleaveIO will be needed. The use of unsafeInterleaveIO would be a (rightly) controversial choice though.

- - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLaK4ACgkQye5hVyvIUKk88QCfRksu7z80QmzgjUvmiyrzDDjl QnsAn1R5DHz2tJpWP3yb0+U+loyBdyCX =RIX9 -----END PGP SIGNATURE-----

Hi,

My opinion is that unsafeXXX is acceptable only when its use is preserved behind an abstraction that is referentially transparent and type safe. Others may be able to help refine this statement.

I would agree with this. The problem is that impurity spreads easily. For example, suppose we have this truly random number generator, 'random'. As soon as we have this, then *almost every* function is potentially impure: f :: Integer -> Integer f x = random + x g :: [Integer] g = repeat random etc. etc. The compiler has no way of tracking impurity other than through the type system which is, of course, exactly what monads do. To echo the sentiment above, the only safe way to use unsafePerformIO is to hide it behind a function that *is* guaranteed to be pure (i.e., returns the same values for the same arguments, can be inlined, etc.). And even then, I would recommend against it. Let me give a *practical* reason why. For a long time, I would never even have considered unsafePerformIO, but I recently had an application that needed unique global identifiers in lots of places, and I was reluctant to pass state around everywhere; *but* I could hide it in a few functions, which were themselves pure. It looked something like: -- Replace (some) name by a number quote :: Integer -> Term -> Term -- Replace a number by (that) name unquote :: Name -> Term -> Term -- Typical usage foo t == let l = getUnsafeUniqueGlobalIdentifier () in unquote l . do some stuff . quote l Since "unquote l . quote l" is an identity operation, 'foo' itself is pure -- provided that nothing in 'do some stuff' relies on the exact identity of the identifier. --- A rule which I broke at some point, got some very strange behaviour, and took me ages to debug. This was mostly due to laziness, which made the point of execution of the unsafe operation to be very difficult to predict. For example, every call to getUnsafeUniqueGlobalIdentifier (it wasn't actually called that, don't worry :-) yielded a number one higher than the previous. However, in a list of terms [t1, t2, .., tn] all of which include some unique idnetifier, it is *not* the generation of the list that determines whether the identifiers in these terms are incrementing, but the *evaluation* of the list -- when are the terms forced to normal form. I was called 'sort' on this list, and sort depended on the values of these identifiers -- but since sort evaluated the terms in the list to normal form in a hard to predict order, the order of the list was anything but sorted! --- Moreover, you need all sorts of compiler options or nasty hacks (the unit argument to getUnsafeUniqueGlobalIdentifier above is no mistake) to avoid the compiler optimizing your code in ways that you did not expect. In the end, I ended up rewriting the entire application to avoid the use of this global unique identifiers, because it was simply too difficult to get right. I felt I was writing C code again and was chasing bugs due to dangling pointers and the wrong memory being used. Not a time I want to return to! Moral of the story: unless you really really need to and really really know what you are doing -- do not use unsafePerformIO. Uncontrolled side effects and lazines will cause extremely hard to track behaviour in your program, and things are almost guaranteed to go wrong. Edsko

...

...

...

...

"Roel" == Roel van Dijk writes:

Roel> On Fri, Feb 6, 2009 at 1:00 PM, Antoine Latter wrote: >> Tangential to all of this - sometimes my unsafeXXX functions >> are pure, but partial.  So I'll have: >> >> foo :: a -> b -> Maybe c >> >> and >> >> unsafeFoo :: a -> b -> c Roel> I use the "unsafe" prefix in the same way. For me it means Roel> 'assume that preconditions hold'. If the preconditions do Roel> not hold and you evaluate an unsafe function anyway I would Roel> expect an error, as opposed to an exception. I have done Roel> that in my (tiny) roman numerals package. Roel> -- simplified toRoman :: Int -> Either String Int Roel> unsafeToRoman :: Int -> String Roel> The first function is very clear about the fact that Roel> something can go wrong. If you provide it with a value of Roel> (-3) it will (hopefully) produce something like 'Left "no Roel> negative numbers allowed"'. The second function hides this Roel> fact and will result in a (uncatchable) runtime error. It is Roel> still a pure function, but preventing errors is now the Roel> responsibility of whoever evaluates it. Do you document the preconditions? It seems to me that this is more useful than naming a function unsafeXXX. I was using comments to document the contracts on my functions, but I have just found about about ESC/Haskell, so I am now using the contract notation of that (not yet released) tool. See http://www.cl.cam.ac.uk/~nx200/ -- Colin Adams Preston Lancashire