For your string-manipulation problem, I don't think you meant to use do-notation. The compiler accepted it because sees it as the list monad, and as a coincidence of the way you wrote it, it did what you expected. Try this, using (let ... in ) syntax.

mkTxt :: (IConnection conn) => conn -> String -> [String] mkTxt conn tS = let wL = words (rpNls tS) ((f,vL):zz) = gtInx wL ["```"] rvL = reverse vL in doIns wL rvL where doIns wL [] = wL doIns wL (v:vs) = let (f,a:b:ss) = splitAt v wL in (doIns f vs) ++ ["aoeeuu"] ++ ss

(Untested.) Next readFile has the signature readFile :: FilePath -> IO String So the way I think of it is that any function using it has to return a result of "IO <something>" You would have to call your pure function mkTxt from inside a monadic computation: run :: IO () run = do zzzz <- readFile "zzpubs.txt" ... -- assuming mkTxt is modified to accept a third arg let result = mkTxt conn ts zzzz print result Finally, yes Haskell complains about type-related faults in identifiers you don't use... because it is trying to help you find your mistakes. How does it know it wasn't a mistake on your part? This is an advantage over script languages. Mike prad wrote:

On Fri, 13 Aug 2010 21:39:33 -0700 prad wrote:

...

"I think It's time for you to get serious with the monads" that's just what i'm going to do!

i'm asking the question in this thread because i think it has something to do with monads though i'm not sure. in fact, the problem seems completely bizarre to me.

i have a function:

mkTxt :: (IConnection conn) => conn -> String -> [String] mkTxt conn tS = do --zzzz <- readFile "zzpubs.htm" let wL = words (rpNls tS) ((f,vL):zz) = gtInx wL ["```"] rvL = reverse vL doIns wL rvL where doIns wL [] = wL doIns wL (v:vs) = do let (f,a:b:ss) = splitAt v wL (doIns f vs) ++ ["aoeeuu"] ++ ss

the program compiles and runs fine. however, if i remove the comment dashes to allow zzzz <- readFile "zzpubs.htm"

the compiler produces what is to me an incomprehensible rationale for an error:

==== gadit.hs:103:4: Couldn't match expected type `IO String' against inferred type `[String]' In a stmt of a 'do' expression: zzzz <- readFile "zzpubs.htm" In the expression: do { zzzz <- readFile "zzpubs.htm"; let wL = words (rpNls tS) ((f, vL) : zz) = gtInx wL ... ....; doIns wL rvL } In the definition of `mkTxt': mkTxt conn tS = do { zzzz <- readFile "zzpubs.htm"; let wL = ... ....; doIns wL rvL } where doIns wL [] = wL doIns wL (v : vs) = do { let ...; .... } ====

i don't do anything with zzzz!! it merely is the name i'm giving to the monadic computation to read in a file. in fact, it has nothing to do with the rest of the function because i don't use it at all.

why is the compiler complaining?

prad wrote:

part of the feeling i'm getting is that a function should only do one thing and i likely try to squeeze too much into it.

I don't think that's universally true, but you may need to stay simple while learning.

i'm used to using a lot of print statements to figure out errors, but may be the idea here is not to make errors because you're functions are written correctly and are precise.

Look at the Debug.Trace module. You can emit debugging messages in a non-safe but usually helpful manner. Be aware that the messages may come in an unexpected order due to laziness. Mike

prad wrote:

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/

prad wrote:

On Sun, 15 Aug 2010 21:11:52 +0200 however, i also have:

======== subs (l:ls) | ls==[] = l : [] | otherwise = case l of "```" -> do let (code:z) = ls str = gt code -- works --str <- readFile "B" -- doesn't work subs (str:z) _ -> l : subs ls

gt s = case s of "B" -> "BBBB" "C" -> "CCCC" ========

Can I make a general suggestion? It looks to me like you need to work through a book like "Real World Haskell" sequentially from the beginning. It looks like you are trying to do complex things before you've mastered simple things. Mike

On Tue, Aug 17, 2010 at 01:59:44PM -0700, prad wrote:

On Tue, 17 Aug 2010 13:34:01 -0700 Michael Mossey wrote:

...

It looks to me like you need to work through a book like "Real World Haskell" sequentially from the beginning.

well i'm doing that too, michael. (i remember you made this suggestion to me several weeks ago and i have worked my way through a few chapters in rw and most of the haskell wiki tutorial).

Well, I may not help you, Prad, but the enormous amount of questions you've send to this mailing-list have helped me to re-discover many basic concepts of Haskell ,-) I am also trying to learn it since last January. So I can add this piece of advice for you : do not rush things. It seems you are reading too many different contents on monads lately. That's strange for someone as lazy as me who cannot digest this much amount of data in such a short time. I usually evaluate my time spend on a specific subject as the number of nights spend between each of my readings and I can say this: monads have taken me a good month of sleep to figure them out :)

what i find interesting is that you say what i'm trying to do here is complicated, because it seemed to me it was one of the simpler things that i actually understood. now i think i'm in trouble, because evidently i haven't understood it too well. :D

No it's not simple. I am not able to read Haskell code which play with database and files, so your code is already behind my understanding.

it seemed to me that in one situation i was trying to get data from a function gt which just returns a string: gt :: String -> String

in the other situation, i wanted to get the same data from a file, but can't seem to because the file is returning an IO instead of a String (in fact it is expecting [String]).

From what I remember, RWH's authors always advocate to separate monadic code from basic code. You should pause for a moment and refactor your code so you do not get caught in this situation again (situation = trying to read a file as you read a String).

If I were you, I would break my problem in even smaller chunks and try to analyze patiently how Haskell could process each individually. regards, /John P.S.: ah ! and keep posting questions on precise problems you encounter. I may be interested in them :p

prad wrote:

On Sun, 15 Aug 2010 21:11:52 +0200 Ertugrul Soeylemez wrote:

...

Just remember this: You have an IO computation? You want to refer to its result? Fine, just use '<-'. That's it.

that's what i've been doing the past two days and it works ... except in one case.

for example, i have:

======== flData <- readFile key let (sec:tle:kwd:dsc:url:typ:dat:txt) = lines flData ========

so flData is the computation which reads the contents of a file and i can take that and do a lines on it. no problem.

I have the impression that you have understood the problem, but you have yet to realize that you have. Your 'subs' function needs the contents of a file, so either you pass those contents explicitly or it needs to become an IO computation, so it can read them itself. Anyway, honestly I don't understand what your 'subs' function is about. It seems to interpret stuff after "```", but you can write this a whole lot simpler and probably more correct, although still very fragile: subs :: [String] -> [String] subs [] = [] subs ("```" : code : ts) = gt code : subs ts subs (t:ts) = t : subs ts Why is this fragile? Well, try the following: subs ["```"] Also do yourself and others a favor and write type annotations at least for all top level definitions. Yes, Haskell has type inference, but for important parts of your code you should really write explicit type annotations. Reason: First of all, the types of your functions are the specification of your program. To write a function, the very first thing you should do is to write its type signature. Never start with the function definition. Sometimes you write a valid function, which doesn't match your intended specification. Also given the type signature you can reason much better about whether your code really does what it should do, without even compiling it. Secondly type annotations make your program far more readable. For some really simple one-liner functions they aren't strictly necessary for readability, but personally I write them even for the simplest functions/values. Now what's the type of your function, when it should read a file? Think about it for a while. One very easy way is to give it the contents of the file as a parameter: subs :: String -> [String] -> [String] Another reasonable way is to let the function read the file itself: subs :: FilePath -> [String] -> IO [String] But beware: The way you were going to do it is very bad. It would read the file once for each occurence of "```". Better read the file at the beginning only, at which point you can just as well split this into two functions: subs :: String -> [String] -> [String] subsUsingFile :: FilePath -> [String] -> IO [String] This particular way to make a nonmonadic functions monadic is called lifting, and because it is such a common thing to do, there are loads of combinators to do it, most notably liftM, fmap and (<$>), which are all the same (though liftM can be used in monads only): liftM :: Monad m => (a -> b) -> (m a -> m b) fmap :: Functor f => (a -> b) -> (f a -> f b) (<$>) :: Functor f => (a -> b) -> (f a -> f b) The subsUsingFile function can be implemented in one of the following ways: -- Raw: subsUsingFile fn ts = do content <- readFile fn return (subs content ts) -- Using lifting: subsUsingFile fn ts = liftM (`subs` ts) $ readFile fn subsUsingFile fn ts = fmap (`subs` ts) $ readFile fn subsUsingFile fn ts = (`subs` ts) <$> readFile fn Further note that you are overusing do-notation, even for nonmonadic code. Read section 6 of my tutorial [1] or a HaskellWiki article about this [2]. Whenever you see this pattern: do x <- c return (f x) you should consider using lifting: f <$> c and don't use do-notation if all you want to do is to make an equation: let x = y in ... especially when your code is not monadic. Your use of the do-notation in your 'subs' function works only incidentally, because it is indeed a monadic function, but not in the IO monad, but in the list monad. [1] http://ertes.de/articles/monads.html#section-9 [2] http://www.haskell.org/haskellwiki/Do_notation_considered_harmful Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/