Crypt Master, CM> Thanks for your help so far, but I am still not CM> getting this IO stuff. After reading your CM> previous help and reading several articles on CM> it I still cant phathom how you convert the IO CM> Int into an Int. Welcome to pure functional programming! :) Well, since you qualify as a beginner to Haskell, the only good answer one can give you is "you *cannot* convert from IO Int to Int. Until you're familiar enough with functional programming in general and Haskell, I'd recommend not to go with any suggestions people will give you on how to achieve this. Trust me. So, first try to ask yourself if it is really needed to get from IO Int to Int. If you're really convinced that it is and that is for nothing but good reasons, then ask again and we might carefully point you to a function that is called unsafePerformIO. (Note: it is called unsafe for a reason.) Now, think about this for a minute. Consider this a function foo :: Int -> Int. In Haskell, I can be sure that whenever I call this function with the same Int argument, I get the same Int result. This observation makes it quite easy for me to reason about this function, e.g. derive some theorems for it. So, I know foo 5 == foo 5 will *always* be True as will foo 6 == foo 6. Then, consider a function bar :: Int -> IO Int. That reads a number from some file, increments the number by argument value, writes the new number back to the file, and produces the new number as the result of the function. (The interaction with the file system makes that the result is included in an IO value.) So, consecutive calls to this function with the same argument will produce different values, won't they? But now imagine now you could somehow convert from IO Int to Int. Then you could use this mechanism to derive a function bar' :: String -> Int that does the same as bar but unwraps the IO Int value to produce an Int. Since consecutive calls to bar' with the same argument are not guaranteed to produce the same values, we cannot rely on bar' 5 == bar' 5 and bar' 6 == bar' 6. Can you see that this troubles reasoning about functions and programs? So, to keep the language 'pure' all stuff inside the IO monad should stay within the IO monad. At first, you might think of this as a limitation, but if you open yourself for it and think about it for a while, and---even better---work with it for a while, I'm sure you will start to appreciate it and start consider it a feature. Well, I might have simplified things here, and perhaps haven't explained in a very clear way: I'm sorry for that. However, I think this is more or less the main reason why the answer to your question should be 'you can't'. HTH, Stefan

The root problem is that random number generation is inherently stateful, and so the familiar imperative idioms don't translate directly into a pure functional language. In a C-like language, each invocation of "rand()" mutates a secret piece of state lurking off-stage; pure functional code doesn't have the option of doing this. What you should probably be using is an infinite list of random numbers (see "randoms" in "Random"). With regard to your IO question, note that "return" "puts the IO back on", as it were; all this is carefully organised so you *can't* quietly file the IO's off values. The trick is to write almost everything in pure functions, then have a little bit of monad-y glue which connects all these ethereal abstractions (what might happen) to the merely contingent (what actually does). Disclaimer: I'm no haskell expert. John P.S. Sorry, but I can't resist this. With apologies to Allen Ginsberg: IO Howl ------- Monad! Monad! Nightmare of Monad! Monad the loveless! Mental Monad! Monad the heavy judger of men! Monad the incomprehensible prison! Monad the crossbone soulless jailhouse and Congress of sorrows! Monad whose buildings are judgement! Monad the vast stone of war! Monad the stunned governments! Monad whose mind is pure machinery! Monad whose blood is running money! Monad whose fingers are ten armies! Monad whose breast is a cannibal dynamo! Monad whose ear is a smoking tomb!

[...] So I am still in IO Int land despite having used the >>= in the do syntax. [...]

The idea of the IO type is that it marks code that can behave differently each time it is called. For this reason, the IO monad 'infects' everything above it in the call chain and, for this reason, the entire program (i.e., Main.main) has type IO (). Rather than trying to extract an Int from the IO monad, you should look at how you can use an Int inside the IO monad. Many programs have a structure like this: read a value, compute a result, display the result. Let's suppose we have a function to do each of these three parts: readValue :: IO Int compute :: Int -> String display :: String -> IO () Note that reading and displaying have side effects and/or depend on the environment so they involve the IO monad. Since they involve a monad, let's use the do notation. Obviously, we start by reading a value: main = do x <- readValue .... The next thing to do is to compute a result. From the types, we know that x has type Int so obviously we want something involving 'compute x'. compute is not in the IO monad so we'll use a let binding instead of '<-': main = do x <- readValue let y = compute x ... Now we want to display y. We know that y has type String so we can apply display to it. 'display y' has type 'IO ()' so we use a monadic binding (<-) instead of a let binding: main = do x <- readValue let y = compute x z <- display y .... Hmmm, what to do with z. It's type is just () so we don't really need to bind it to anything so let's drop the binding to get the complete program: main = do x <- readValue let y = compute x display y Let me summarise what went on here: 1) If something has monadic type (i.e., has side effects or depends on the environment it is run in), use '<-' to bind the (non-monadic) result to a variable. 2) If something is not monadic (i.e., doesn't affect the world and doesn't depend on the world), use 'let' to bind the (non-monadic) result to a variable. 3) If something has a monadic type but we don't care about the result (so, presumably, it has an interesting side effect) you can drop the 'blah <-' part. [This last rule makes more sense if you use >>= and >> instead of the do notation. >>= corresponds to binding a result using '<-' while

...

corresponds to not binding a result.]

Another way of looking at it is that the IO monad infects the type of everything _above_ it in the call chain but doesn't infect the type of things _below_ it. So if you have a pure function like 'compute', you just call it from within the IO monad rather than trying to get out of the IO monad, call compute and then go back into the IO monad when you want to display the result. I hope this helps, -- Alastair Reid

Judging from a previous message I'm not sure if you're still using SOE, but one of the things I tried to do is introduce IO without mentioning monads at all, and if you read chapter 3 (especially section 3.1) you will see that that's the case. To those who have had imperative programming experience, I think that section 3.1 should not present any problems. But it sounds as if you've gotten past that, since you quoted something from chapter 18, where the "mysteries" of IO are revealed in gory detail. It looks like lots of people have given you good advice, but I'll throw in one more idea about how to "convert an IO Int into an Int". Although, as many have pointed out, you can't really do this in a technical sense, you can get the effect that you want as follows: Suppose you have a function foo of type IO Int, and you wish to apply a function bar of type Int -> T to the value you get from foo (T is some result type). Then all you have to do is this:

do i <- foo return (bar i)

This is what people meant by "writing a little monadic scaffolding" to achieve what you want. The function bar is a pure function that does not involve IO at all. It may involve dozens of page of code, but you need the two lines of "scaffolding" above in order to invoke it. Now, in the end, you might say that we haven't achieved much, because the above expression has type IO T, so all we've really done is convert an IO Int into an IO T. Quite true! That's why most of the people who responded to your email eventually wrote something like:

do i <- foo putStr (show (bar i))

or whatever, in order to actually generate some useful output. Indeed, that useful output might also include writing to a file, displaying some graphics, etc. I hope this helps, -Paul Crypt Master wrote:

Hi

Thanks for your help so far, but I am still not getting this IO stuff. After reading your previous help and reading several articles on it I still cant phathom how you convert the IO Int into an Int.

One person mentioned how random just returns an interative program which when eveluated returns the Int. Also from the school of expression book he says " The right way to think of (>>=) above is simply this: It "Executes" e1 ..." in relation to "do pat <- e1 ...".

so I have this:

<code> rollDice :: IO Int rollDice = getStdRandom (randomR (1,6))

rl :: [Int] rl = [ (getRndNum x) | x <- [1..] ]

getRndNum :: Int -> Int getRndNum x = do n <- rollDice return n </code> *PS Pretend return is correctly aligned under n. dont what ahppens in copy and paste*

now my understanding therefore is that "do n <- rollDice" should execute the the itererative program returned by rollDice. So now n should be my Int since IO Int was a program which when evaluted returns an Int ?

However this is what haskell thinks of my thoery:

*** Term : getRndNum *** Type : Int -> IO (Maybe Int) *** Does not match : Int -> Int

So I am still in IO Int land despite having used the >>= in the do syntax. Worse Still I am in IO (Maybe Int) land. Monads within Monads.

In yours, and many other examples I found online, the results are always passed to print which seems to know how to deal with an IO Int. Is this specially coded or overloaded or something ?

There are plenty of examples which use return like so:

do k <- getKey w return k

which is what I tried above to no avail.

It seems awefully complicated just to get hold a simple Int, but naturally complicity is directly related to ones understanding. Mine is sumewhat lacking ... any help would be appreciated.

Thanks,

S