Chris Smith <cdsm...@gmail.com> писал(а) в своём письме Fri, 30 Dec 2011
22:28:36 +0200:
I really think that the notion of “purity” appeared to convince C
programmers. It would be silly to try to explain that “Int -> IO Int”
isn't really a function from Int to Int, monads, blah blah blah. So, we're
saying: “here is a function which accepts Int and (sic!) returns Int, but
it can also do IO, which is kinda unsafe. So we are marking it with ‘IO’
letters, see? This means that this function is ‘impure’. And to prevent
mixing pure things with impure things, compiler demands you to mark with
IO every “function” which ‘uses’ IO”.
Functions don't use IO. Funtions return IO <something>. And functions
returning IO are impure. That's all.
This is a valid concern... assigning a meaning to values of IO types
necessarily involves some very unsatisfying hand-waving about
indeterminacy, since for example IO actions can distinguish between
bottoms that are considered equivalent in the denotational semantics of
pure values (you can catch a use of 'error', but you can't catch
non-termination). Nevertheless, I'm satisfied that to the extent that
any such meaning can be assigned, f will be a valid function on
non-bottom values. Not perfect, but close.
Agree. The fact that IO actions can distinguish between bottoms,
self-modify code, terminate non-terminable computations by rebooting the
system, send killbots to the programmer's house and so on are extremely
unsatisfying. That's IO for you.
The dirty impure bottom comparison which uses IO, though, is available
only to already impure functions.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
