Oh, you sure?
<quote src="http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html
">
It is less well known that unsafePerformIO is not type safe. For
example:
test :: IORef [a]
test = unsafePerformIO $ newIORef []
main = do
writeIORef test [42]
bang <- readIORef test
print (bang :: [Char])
This program will core dump. This problem with polymorphic references
is well known in the ML community, and does not arise with normal
monadic use of references. There is no easy way to make it impossible
once you use unsafePerformIO. Indeed, it is possible to write
coerce :: a -> b with the help of unsafePerformIO. So be careful!
</quote>
That's the reason why "f" has sometimes LESS general type than "\x ->
f x" in OCaml.
On 10 May 2008, at 01:34, Achim Schneider wrote:
Miguel Mitrofanov <[EMAIL PROTECTED]> wrote:
As I understand it Haskell does not specify an order of evaluation
and it would therefore be a mistake to write a program which relies
on a particular evaluation order. This is the 'unsafe' aspect of
unsafePerformIO.
Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type
errors in runtime. At least, that seems to be much more dangerous.
Nope. That'd be unsafeCoerce#, which you never heard of, and I did not
mention it in this post. Go away. This is not the function you are
looking for.
--
(c) this sig last receiving data processing entity. Inspect headers
for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
