Using GHCi I found it informative to see that IO indeed is a kind of state monad. Here's a GHCi session to show that: Prelude> :m GHC.Prim Prelude GHC.Prim> :i IO newtype IO a = GHC.IOBase.IO (State# RealWorld -> (# State# RealWorld, a #)) -- Defined in GHC.IOBase instance Monad IO -- Defined in GHC.IOBase instance Functor IO -- Defined in GHC.IOBase So every "IO a" action takes the RealWorld as input, and outputs the RealWorld and some extra value "a" :) 2008/12/23 Adrian Neumann

Am 23.12.2008 um 15:16 schrieb Hans van Thiel:

Hello All,

...

I just saw somewhere that one of the purposes of monads is to capture side effects. I understand what a side effect is in C, for example. Say you want to switch the contents of two variables. Then you need a third temporary variable to store an intermediate result. If this is global, then it will be changed by the operation.

But the two variables have also changed. After all they have different values after the switch. You see, even locally changing a variable is a side-effect. It changes the state of the program. Pure Haskell programs on the other hand have no notion of state, there are no variables which can change their value. Every time you want to manipulate something you're actually generating an new copy. You mustn't think of a haskell program as a series of changes to some state.

However when you *do* want state you can simulate it with a monad. The IO Monad is a special case here, since its actions don't change your program, they change the "world" the program is running in (writing files etc.). getLine etc are functions when you think of them as taking a hidden parameter, the state of the world. So getChar would become

getChar :: World -> (Char,World)

but the world stays hidden inside the IO Monad.

Regards,

Adrian

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hans van Thiel wrote:

However, some functions in Haskell may have side effects, like printing something on the screen, updating a database, or producing a random number. These functions are called 'actions' in Haskell.

Not really true (disregarding things like unsafePerformIO). I haven't been following this thread, so I don't know if anybody else has suggested this, but perhaps it would be helpful to distinguish between evaluating expressions and performing actions. Evaluation is simply graph reduction, which is Haskell's only method of computation. There are no side-effects when you evaluate an expression (again, disregarding unsafePerformIO and company), even if that expression evaluates to an IO action. To perform an action is to cause the side-effect which that action represents. *You* never perform an action in Haskell. The runtime does. All you do is say how to evaluate those actions. Essentially, what the IO monad does is give you a DSL for constructing (by evaluation) effectful, imperative programs at runtime. The runtime will cause your program to evaluate the next action, then perform it, then cause your program to evaluate the next action, then perform it, and so on. At no point is the purity of your program broken by this.

However, there is a mechanism (sometimes) to compose functions using an extra type m a, m b, m c etc. instead of types a, b, c... This does not solve the problem concerning side effects, but it does provide a sort of 'Chinese boxes' to contain them within these type constructors m. Moreover, in the case of the type designation 'IO ...', you can't get anything out of the box. So now, at least, you've got a clean interface between the parts of your program which do not involve side effects, and the 'actions'.

This is another way to think of it. It is how I first thought of IO before I discovered the way I described above. It's a pretty good metaphor, and I don't think it's harmful, so you can stick with it for now if you would prefer.

If I guess correctly, then the general statement 'monads are for actions' is wrong. It should be something like, 'monadic composition is a useful method of generalization, which, by the way, allows you to isolate side effects in a controlled manner'.

Right on. Monads are extremely useful for things that don't involve side-effects. Hope this helps, - Jake

On Sat, Dec 27, 2008 at 4:50 PM, Hans van Thiel wrote:

However, some functions in Haskell may have side effects, like printing something on the screen, updating a database, or producing a random number. These functions are called 'actions' in Haskell.

No :D I'll try to explain using the same picture that came into my mind when I first got what monads really are... Everything in Haskell is a function AND an Haskell function is always pure, i.e. has no side effects. Functions may return "actions", which are a special kind of value even though they are no different to Haskell from values of any other type. When you are returning an action is like when you go to a driver and give him a car: the driver takes the car you gave him and takes it wherever the car is supposed to go. You build the car using small pieces (i.e. basic functions returning actions like putStrLn) and putting everything together using combinators (like >>= and >> or the "do" notation). So, the car in the example is an "action" (or, more formally, a value in a monad). Your Haskell functions (like putStrLn or anything) just return the car, but they don't run it: they are run at run-time by the Haskell run-time environment whose only task is to run values in the IO Monad, i.e. running the car. Even it may not be apparent for the IO Monad, every Monad value is run at some point in time: almost every monad is associated to at least a function running the monad: for the State Monad this is runState, for the Reader Monad is runReader and so on. The only exception to this is the IO Moand, which can be run only by the Haskell run time, implicitly: this is the reason why you'll never see a "runIO" thing. When the monad is run, it generate side-effects, like printing to screen, opening file and so on. If you're used to Unix administration, another image to understand monads are scripts. Haskell functions return script files that are run by the shell to affect the system they are run on. In the end, they are small pieces (the basic commands present in the system) put together by bash constructs, like "for", "while" and so on. Hope this helps. -- Cristiano

Everything in Haskell is a function [...]

Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a->b for some types a & b). - Conal On Sat, Dec 27, 2008 at 12:16 PM, Cristiano Paris wrote:

On Sat, Dec 27, 2008 at 4:50 PM, Hans van Thiel wrote:

...

However, some functions in Haskell may have side effects, like printing something on the screen, updating a database, or producing a random number. These functions are called 'actions' in Haskell.

No :D I'll try to explain using the same picture that came into my mind when I first got what monads really are...

Everything in Haskell is a function AND an Haskell function is always pure, i.e. has no side effects.

Functions may return "actions", which are a special kind of value even though they are no different to Haskell from values of any other type.

When you are returning an action is like when you go to a driver and give him a car: the driver takes the car you gave him and takes it wherever the car is supposed to go. You build the car using small pieces (i.e. basic functions returning actions like putStrLn) and putting everything together using combinators (like >>= and >> or the "do" notation).

So, the car in the example is an "action" (or, more formally, a value in a monad). Your Haskell functions (like putStrLn or anything) just return the car, but they don't run it: they are run at run-time by the Haskell run-time environment whose only task is to run values in the IO Monad, i.e. running the car.

Even it may not be apparent for the IO Monad, every Monad value is run at some point in time: almost every monad is associated to at least a function running the monad: for the State Monad this is runState, for the Reader Monad is runReader and so on.

The only exception to this is the IO Moand, which can be run only by the Haskell run time, implicitly: this is the reason why you'll never see a "runIO" thing.

When the monad is run, it generate side-effects, like printing to screen, opening file and so on.

If you're used to Unix administration, another image to understand monads are scripts. Haskell functions return script files that are run by the shell to affect the system they are run on. In the end, they are small pieces (the basic commands present in the system) put together by bash constructs, like "for", "while" and so on.

Hope this helps.

-- Cristiano _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris wrote:

On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote:

...

...

Everything in Haskell is a function [...]

Where did this idea come from?

I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a->b for some types a & b).

Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves.

Cristiano

I think most of the introductory material I've seen that made me go "aha now I get it" say pure functional programming is about values, and transformations of those values, and that functions are also values. Then they usually go into admitting that that's only really good for heating up the CPU and that I/O and side-effects have to be made possible, but they're not willing to give up what they won for us by having everything be a value... then monads enter the discussion or "actions", and then monads get introduced later. Dave

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Cristiano, Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative). And yet I've heard "everything is a function" on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations: * In pure "OO" programming, everything is an object, so in pure "functional" programming, one might assume everything is a function. I find the term "value-oriented programming" a more accurate label than "functional programming". * C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as "functions", whether they're of function type or not.) Are there other thoughts & insights about the source of the idea that "everything is a function"? Thanks, - Conal On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris wrote:

On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote:

...

...

Everything in Haskell is a function [...]

Where did this idea come from?

I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a->b for some types a & b).

Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves.

Cristiano

Granting the "everything is a function" idea the best intent, maybe what it's trying to express is the related but different notion that everything *can be* a function -- i.e. that any value can be replaced by a function which yields a value of the appropriate type. Alternately, it could be a confusion between the untyped lambda calculus, in which everything really is a function, and the typed lambda calculus, in which things are more complicated? --S. On Jan 2, 2009, at 2:53 PM, Conal Elliott wrote:

Hi Cristiano,

Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative).

And yet I've heard "everything is a function" on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations:

* In pure "OO" programming, everything is an object, so in pure "functional" programming, one might assume everything is a function. I find the term "value-oriented programming" a more accurate label than "functional programming".

* C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as "functions", whether they're of function type or not.)

Are there other thoughts & insights about the source of the idea that "everything is a function"?

Thanks,

- Conal

On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris wrote: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote:

...

...

Everything in Haskell is a function [...]

Where did this idea come from?

I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a->b for some types a & b).

Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves.

Cristiano

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

"Reiner Pope" wrote:

2009/1/3 Conal Elliott :

...

Are there other thoughts & insights about the source of the idea that "everything is a function"?

Lazy evaluation can make values seem like functions, given that laziness can be modeled in a strict imperative language by 0-argument functions.

Also, in an uncurried language, decreasing the number of arguments to a function, still keeps it a function, eg foo(int a, int b); // 2 arguments foo(int a); // 1 argument foo(); // 0 arguments, but still a function In a strict language, there is a distinction between 0-argument functions and values; there isn't in Haskell, but it is still nice to maintain the idea of "0-argument functions" in Haskell -- which are just values.

You can factor a cool intuitive understanding about IO actions not being the action itself, but just tokens that represent an action, out of this, by adding just one sentence. I guess the proper way to offset functions and values depends on what you want to explain, and multiple views on the same thing can't hurt. Conal, you aren't interrogating the list to figure out how to write a Haskell version of the wizard book, are you? We'd have to stop the pizza deliveries if you stop working on reactive... ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Adrian Neumann wrote:

Am 23.12.2008 um 15:16 schrieb Hans van Thiel:

...

I just saw somewhere that one of the purposes of monads is to capture side effects. I understand what a side effect is in C, for example. Say you want to switch the contents of two variables. Then you need a third temporary variable to store an intermediate result. If this is global, then it will be changed by the operation.

[...]

However when you *do* want state you can simulate it with a monad. The IO Monad is a special case here, since its actions don't change your program, they change the "world" the program is running in (writing files etc.). getLine etc are functions when you think of them as taking a hidden parameter, the state of the world. So getChar would become

getChar :: World -> (Char,World)

but the world stays hidden inside the IO Monad.

Yes, I like this view, but you shouldn't say that the world is hidden inside the IO monad, because you can easily use part of that state in computations. In my view, the IO monad is some notion of this: type IO = State World The main difference between this and the real IO is that there is no value for the (entire) world's state you could refer to, which eliminates the need for 'get', 'put', and by introducing a 'main' computation, also 'runState' becomes unnecessary. In fact, this makes the whole 'World' type unnecessary. So IO is really just a theoretical construct to make input/output consistent with referential transparency. This is a very short version of what I have written in section 7 [1] of my monads tutorial. [1] http://ertes.de/articles/monads.html#section-7 Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/