Am Mittwoch, 21. Dezember 2005 13:15 schrieb Creighton Hogg:

[...]

Monads, I believe, can be just thought of as containers for state.

I would say that you are talking especially about the I/O monad here. A monad as such is a rather general concept like a group is in algebra. The important point of the integration of imperative programming in Haskell is not that it's done using monads. The point is that you have a specific type (IO) whose values are descriptions of I/O actions, and some primitive operations on IO values. The IO type together with two of these primitive operations forms a monad but this is secondary in my opinion.

[...]

Best wishes, Wolfgang

Am Mittwoch, 21. Dezember 2005 16:28 schrieb David Barton:

Wolfgang Jeltsch writes: ----- Original Message -----

...

Am Mittwoch, 21. Dezember 2005 13:15 schrieb Creighton Hogg:

...

[...]

Monads, I believe, can be just thought of as containers for state.

I would say that you are talking especially about the I/O monad here. A monad as such is a rather general concept like a group is in algebra.

While this is correct, I'm afraid that for most of us it is a flavorless answer. I wish I had the mathematical mind that made the word "group" in this context instantly intuitively recognizable, but I don't.

The point is that the concept of a monad is a rather abstract one. Maybe we should take vector spaces instead of groups. A vector space is just a set together with two operations, namely vector addition and scalar multiplication whereby the operations have to fulfill a couple of laws. One law, for example, would be that vector addition is commutative. The point is that this vector space concept is very general. There are a lot of concrete vector spaces which all fit that general idea. For example, R^2 together with the commonly defined vector addition and scalar multiplication is a vector space. But there are many others, lots of which seem to have nothing to do with R^2 and its operations from the first sight. So we have a general concept "vector space" and a lot of concrete vector spaces. Now, "monad" is a general concept like "vector space". In Haskell terms a monad is a type of kind * -> * (i.e., a type which needs to be applied to one type parameter in order to be able to be used as a type of expressions) together with operations (>>=) and return whereby (>>=) and return have to have specific types and have to fulfill certain laws. IO together with its (>>=) and return is an example of a concrete monad. [] together with concatMap and \x -> [x] is another one. This may seem very surprising at first ("What do lists have to do with I/O computations?") but it's really so.

I think Phil Wadler said it best when he said that a monad is a *computation*.

No, a value of type IO <something> is a computation. The type IO plus (>>=) plus return is a monad. So is [] plus concatMap plus \x -> [x].

[...]

Dave Barton

Best wishes, Wolfgang

Am Mittwoch, 21. Dezember 2005 19:02 schrieben Sie:

[...]

You (or, rather the processor) don't execute instructions to write "Hello" in same way as, say, adding 2 and 2.

Exactly!

Rather, you add writing this string to a "to do" list and wait for a driver to respond to an interrupt, pick up the request(s), and carry it (them) out when control passes back the kernel.

I don't completely understand what you mean but I think it goes into the right direction. We can illustrate the process of executing a Haskell program as follows. We have a "evaluation machine" and a "execution machine". The former evaluates expressions, the latter executes I/O actions. When the program is started, the execution machine wants to execute the actions from the "main to do list". In order to be able to do so, it asks the evaluation machine to start evaluating main. For each entry on the to do list, main is evaluated as far as it's necessary to provide the execution machine with the entry. Of course, evaluating main may result in evaluating other expressions. The point is that the evaluation machine does never execute any I/O actions while the execution machine is unable to do any evaluation but needs to be feeded by the evaluation machine. Best wishes, Wolfgang

On 21/12/05, Cale Gibbard wrote:

On 21/12/05, Daniel Carrera wrote:

...

Hi all,

I'm a Haskell newbie and I don't really understand how Haskell deals with functions that really must have side-effects. Like a rand() function or getLine().

I know this has something to do with monads, but I don't really understand monads yet. Is there someone who might explain this in newbie terms? I don't need to understand the whole thing, I don't need a rand() function right this minute. I just want to understand how Haskell separates purely functional code from non-functional code (I understand that a rand() function is inevitably not functional code, right?)

Cheers, Daniel.

Haskell separates pure functions from computations where side effects must be considered by encoding those side effects as values of a particular type. Specifically, a value of type (IO a) is an action, which if executed would produce a value of type 'a'.

Some examples: getLine :: IO String putStrLn :: String -> IO () -- note that the result value is an empty tuple. randomRIO :: (Random a) => (a,a) -> IO a

Ordinary Haskell evaluation doesn't cause this execution to occur. A value of type (IO a) is almost completely inert. In fact, the only IO action which can really be said to run in a compiled Haskell program is main.

Now, so far, all this is great, but without a way to chain actions together end-to-end, we can't do a whole lot. So Haskell provides us with a few primitives for composing and chaining together IO actions. A simple one of these is: (>>) :: IO a -> IO b -> IO b where if x and y are IO actions, then (x >> y) is the action that performs x, dropping the result, then performs y and returns its result. Great, we can now write programs which do multiple things: main = putStrLn "Hello" >> putStrLn "World" will print "Hello" and "World" on separate lines.

However, we don't yet have a way to chain actions in which we are allowed to use the result of the first in order to affect what the second action will do. This is accomplished by the following operation, called 'bind': (>>=) :: IO a -> (a -> IO b) -> IO b Now, if x is an IO action with a result of type 'a', and f is a function from values of type 'a' to actions with a result of type 'b', then x >>= f is the action that performs x, and captures its result, passing it to f, which then computes a second action to be performed. That action is then carried out, and its result is the result of the overall computation.

That's a mouthful, but once you see it in use, perhaps the idea will become clearer: main = putStrLn "Hello, what is your name?" >> getLine >>= \name -> putStrLn ("Hello, " ++ name ++ "!")

This is most of what we need. In fact, this bind function is really successful, and we can define (>>) in terms of it: x >> y = x >>= const y

In practice, it turns out to also be quite important to turn a value into an IO action which does nothing, and simply returns that value. This is quite handy near the end of a chain of actions, where we want to decide what to return ourselves, rather than leaving it up to the last action in the chain. So there's one more primitive, return :: a -> IO a which does just that.

Note that there is no function: unsafe :: IO a -> a as this would defeat the referential transparency of Haskell -- applying 'unsafe' to the same IO action might return different things every time, and Haskell functions aren't allowed to behave that way.

Now, I haven't really told you anything about monads in general yet. Most monads are actually rather unlike IO, but they do share the similar concepts of bind and return. For monads in general, see my tutorial MonadsAsContainers on the wiki :)

Hope this helps - Cale

Oh, just sent that, but there was one more point I wanted to make. You might see do-notation all over the place in real Haskell programs. In do-notation, our example program might look like: main = do putStrLn "Hello, what is your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!") This is in fact entirely equivalent to the above form, and is translated into it by the Haskell compiler. So whenever you see a do block, you can just imagine a chain of applications of (>>) and (>>=), and some lambdas when appropriate to capture the results of actions. - Cale

On 21/12/05, Daniel Carrera wrote:

Thanks for all the help. I think things are much clearer now. And this bit:

...

main = do putStrLn "Hello, what is your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!")

Looks quite straight forward.

I just wrote my very first IO program with Haskell: --//-- main = do x <- getLine putStrLn( show(length x) ) --//--

That's not so scary. The next thing I need to figure out is how to act on the input data itself (not just its length). For example, if I wanted a program to output the nth element of the fibonacci sequence: --//-- $ ./fib 12 144 --//--

My first inclination would be to write it as: --//-- main = do x <- getLine putStrLn( show(fib x) ) --//--

Of course that won't work because x is an IO String and 'fib' wants an Int. To it looks like I need to do a conversion "IO a -> b" but from what Cale said, that's not possible because it would defeat the referential transparency of Haskell.

Actually, you're closer than you think here. x is actually of type String! The problem is just that fib wants a number, so you need to read the string: main = do x <- getLine putStrLn (show (fib (read x))) There's a handy name for the composite (putStrLn . show) called 'print', so you can write: main = do x <- getLine print (fib (read x))) Cheers! - Cale

Creighton Hogg wrote:

x is a String, getLine has type IO String. That's what I was getting at in one of my last e-mails.

Hmm... let's see if I understand: * getLine() has type IO String. * The <- will "convert" an IO String to a plain String * So if I do x <- getLine() then x has the type String. So, the <- effectively ammounts to an IO a -> a conversion. In another email John Hughes said that one could think of "IO a" as a set of instructins for obtaining a. I guess that means that IO is a sort of imperative layer that helps the purely functional code interact with the outside world. So I can have an IO bit (e.g. a do-block) that calls functions (which are purely functional code) but I can't have a function that executes any IO. For example, it is not possible to write a function "my_read_file" that could work like this: my_data = my_read_file("my_file.txt") Correct? Otherwise this would be a function that is not referentially transparent. Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/ I am not over-weight, I am under-tall. /

Hello Daniel, Wednesday, December 21, 2005, 6:24:29 PM, you wrote: DC> So I can have an IO bit (e.g. a do-block) that calls functions (which DC> are purely functional code) but I can't have a function that executes DC> any IO. it's true DC> For example, it is not possible to write a function "my_read_file" that DC> could work like this: DC> my_data = my_read_file("my_file.txt") DC> Correct? Otherwise this would be a function that is not referentially DC> transparent. you are right. type "IO a", after all, stands for "RealWorld -> (a,RealWorld)", i.e. it gets RealWorld as parameter and returns, besides value of type "a", a new RealWorld state. the function which type don't ended with "IO a", just can't receive or return value of type RealWorld, so there is just no way to check something outside or return new state of the outer world -- Best regards, Bulat mailto:bulatz@HotPOP.com