On 20/05/2008, at 3:54 PM, Zsolt SZALAI wrote:

Here comes IO and one-way monads, where the internal state can not be
extacted, and seems, that the internal data is global to the program.
Hows that could be? Is it just because main::IO() or because the
implementation of IO uses external C functions and there are no
internal state in the monad itself at all?

Operationally, the IO monad doesn't have any internal state. The 'state' would be the outside world - which can't really be represented at runtime.

The IO monad is a state monad that passes around a special token that / represents/ the outside world. What the token actually is doesn't matter, but passing it around in a single threaded manner in the Core IR provides data dependencies that ensure that operations on the world happen in the correct order. References to this token actually get erased before code generation. In GHC this erasure is called the 'state-hack'.

And why one can not write a function that makes an IO computation and
the return type does not include and IO contructor? It is a feature of
the language and specific to IO, or anybody  could write a monad with
this property(one-way), assuming the implementation does not use
external languages?

IO isn't a feature of the language, it's a type defined in the library. You can define your own IO-style monads if you like.

Or the one-way property is just that, there is no such functions, that
allow extracting internal data?

Just that. It's one way because there are no functions convert an 'IO a' into an 'a' (mostly). Doing that would break the desired single- threadedness property.

If you're convinced that violating this single-threadedness won't break your program you can use unsafePerformIO :: IO a -> a, but this performs the action, it doesn't give you the actual world token.

Ben.


_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to