
prad
On Sun, 15 Aug 2010 16:43:09 +0200 Ertugrul Soeylemez
wrote: I'm not sure whether you are reading our posts, but we have explained in detail the difference. Once understood, you won't get errors like that anymore.
As a well meant suggestion, you have to actually read the answers to your posts, even if they are long.
believe me i read the posts (more than a few times) - especially yours in fact and am very appreciative. however, it takes me a while to understand what's going on - even to connect similar ideas together. i certainly don't mind long posts either, but i am still having difficulties putting the ideas together. i tend to be a bit slow anyway and keep thinking in python terms.
i intend to respond once i understand the ideas better. for instance, what you wrote here made sense to me:
======== let readBlahTxt = readFile "blah.txt" content <- readBlahTxt
This should show the difference more clearly. ========
however, i still can't quite connect it to the idea of what it has to do with getting monad data out of a monad and into the pure realm. late last night, though, i was able to do so, but it took while.
I'd say don't bother. "Getting out of" is just a metaphor. Monads are no boxes. You have a monadic computation, which has a result, and you want to refer to this result, and that's all. let a = getLine b <- getLine In this example, 'a' is the same as 'getLine'. It's a computation, which reads a line from stdin. It's not the result of the computation (String), but the computation itself (IO String), because you defined 'a' and 'getLine' to be the same thing. On the other hand, 'b' is the result. You could just as well write: b <- a Just remember this: You have an IO computation? You want to refer to its result? Fine, just use '<-'. That's it. Now what is meant by the "getting out of" metaphor? You can use the '<-' notation only inside of a monadic computation. In other words, even though you can refer to the result of getLine, ultimately you are making a new IO computation, which uses the result: readAndSquare :: IO Integer readAndSquare = do line <- getLine let n = read line return (n^2) readAndSquare is an IO computation itself and there is nothing you could do about it. As long as you refer to results of IO computations, if you go down the call tree, you will always end up in an IO computation. This is what people refer to as not being able to "get out of" IO. This is not true for the list monad: getFirstWord :: String -> String getFirstWord = head . words The list concept is also a monad, or in Haskell terms: [] is a monad. You are using the result of a monadic computation, namely 'words': words :: String -> [String] -- brackets style words :: String -> [] String -- prefix style But the getFirstWord function is itself not monadic (let's disregard the fact that strings are lists). Using the 'head' function head :: [a] -> a -- brackets style head :: [] a -> a -- prefix style you have broken out of the [] monad. There is no such function for the IO monad: breakOut :: IO a -> a Well, that's not entirely true. There is unsafePerformIO, which has exactly that type signature, but seriously, never use it. Especially as a beginner coming from the imperative world one is often tempted to use it, but don't. Using it is almost always the wrong approach, and as its name suggests a very unsafe one, too.
Posting essentially the same questions over and over gets you nowhere.
agreed and i apologize. my problem is that i don't even see that it is the same question. as you have pointed out once before, "You're still thinking way too complicated."
i think what happens is i keep trying different things over and over again. that affects my thinking no doubt. i should likely think more and try less.
In fact, I recommend not to think more, but to think less. Forget the word 'monad' and just concentrate on specific monads like IO or Maybe. At some point it will make click and suddenly everything gets clear. Everybody has this experience with monads (unless they give up).
I don't like to mention my own one
i would very much like to see yours.
It's linked on the tutorials wiki page as "Understanding Haskell Monads".
I agree with Brent
i think brent's delightful blog post describes my present dilemmas ... except i haven't quite gotten to the point of being able to say "monads are burritos" ... so i think there is likely still hope for me. ;)
Try this [1]. ;) [1] http://blog.plover.com/prog/burritos.html Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/