Hello,

On 8/1/07, Andrew Wagner wrote:

...

For me, I think the key to monads is to really understand 2 things about them: ... 2.) Monads are about sequencing

Now I disagree on 2.

Monads are no more about sequencing than binary operators are about sequencing. Sure, if you want to, you can define an operator like (*) to be non-commutative, so that a*b is different to b*a, but that doesn't really get to the essence of what a binary operator is. And in everyday usage we use (*) to mean ordinary commutative multiplication where there is no sense of sequencing.

The same holds for monads. If you want to use them for sequencing the option is there, but there are plenty of commutative monads out there, for which the order of operations doesn't matter, and the fact that they are commutative doesn't make them any less monads. So while you can use monads to sequence, I don't think sequencing gets to the essence of what monads are.

I suspect I hold a minority view here... :-)

You are entirely correct. Data dependencies enforce/specify sequencing. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

On 2 Aug 2007, at 5:13 am, alpheccar wrote:

I think the problem is due to a few bad tutorial still available on the web and which are making two mistakes:

1 - Focusing on the IO monad which is very special ; 2 - Detailing the implementation. As a newie we don't care and we would prefer to see how to use monads rather than how to develop monads.

When you look at monads you see they can be used for controlling the evaluation order (list monad, error monad, IO monad). They can be used for side effects (IO, state monad). They can be seen as containers (list, Maybe). They can be used to provide a protected environment (tainting). So, it is difficult to see what they have in common. Of course, what they have in common is a set of algebraic laws : the monadic laws but it does not help to know it.

I think that a way to see monads (and a consequence of the monadic laws) is that monads are interpreters for domain specific languages.

And so on. But please, let's keep one foot in the real world if possible. Monads were invented to solve the "how do I do imperative programming in a pure functional language" problem. We teach schoolchildren how to add. They spend years counting and adding before we point out that x+y == y+x. Most people leave high school without EVER having to know that the whole numbers are a ring or what that means. When they DO learn that, the only way they can really make sense of it is to turn it back to front "a ring is a collection of things and operations that is rather like whole numbers". In order to get almost anything *done* in a Haskell program, you HAVE to learn about the IO monad. You can get an amazing amount of useful stuff done without EVER learning about any other monad at all. The IO monad gets in your face all the time. You teach the IO monad before anything else about monads because if you *don't* teach about that, if you delay it any longer than you have to, the students become convinced that you can't do anything useful in Haskell and lose interest in learning anything else about it. Focussing on the implementation? Well, I believe in giving my students the original papers. One of them is "How to Declare an Imperative". Telling the students about the implementation is *important* to *gain their trust*. There's magic in Haskell, but THIS isn't magic. I go over it again and again: ">>= acts like semicolon; it's all about sequencing." If you've read the Science of Discworld books you will be familiar with the phrase 'lies-to-children'. You DON'T tell them the full truth, because it would take a long time, confuse the marrow out of their bones, and leave them feeling this was masturbatory mathematics, not real programming, having no connection with real world interests. Once they are reasonably comfortable with the IO monad, you can introduce ST. Once they are reasonably comfortable with the use of ST for arrays, you can show them the axioms that are required for monads to work the way we expect. Once they have got *that*, you can then show them that Maybe is a monad in that we can define the operations in a useful way that also satisfies the axioms. Then we can go onto other monads, except that in a first course, there isn't time for that. But at least we haven't scared them off completely by telling them that monads are interpreters.

The outermost monad (rightmost bound function) is in the driver seat, and is absolutely free to ignore the monad to its left (which in turn encloses monads to its left)! This includes of course the main input IO () monad. Don't believe me?

Prelude> const 3 (return "Nuclear waste leaking..." >>= print) + 5 8

Phew, no nuclear waste leaked after all. What a relief!

No, I don't believe you. It's true that the right monad instance can ignore its left sibling (same monad of course, just a different instance) to allow backtracking (the Const monad being a trivial example of this), but IO is not such a monad. Your example just shows that monad instance expressions (like any Haskell expression) are evaluated lazily in Haskell. I am relieved though, that no nuclear waste was leaked by your example. Dan Weston wrote:

Here's my rant about the way monads are explained in Haskell tutorials (which are much too polluted with nuclear waste to be safely approached):

It is a big mistake to start with the IO monad. It pollutes and misdirects the understanding of what a monad is. The dreaded "nuclear waste" metaphor is actually a red herring, having nothing do do with a monad at all, merely the artifact of the absence of an exit function in the IO monad (which actually does exist and is called unsafePerformIO, but that is a secret. Shhh...), combined with Haskell's refusal to work for free.

Monads are required to have an extrance (reification/constructor function) called return. They are *not* required to have an exit (reflection/deconstructor function).

They *do* combine (bind) together like links in a chain, which is not a list but an equivalence class of trees, where the only thing that matters is the order of the leaves, so unlike a list you don't have to start at the tail and assemble one-by-one. [Actually, the compiler picks just one of these trees (the singly-linked list) but expects that all trees would evaluate the same.]

They *do* bind only with flavors of themselves (State a cannot bind to IO b, though a monad transformer can merge the two). The output type of one monad instance must match the input type of another monad reification function (e.g. return) that it wants to bind to.

In compensation for this tribalism, those snobby monads that want to clique off are out of luck: a monad cannot restrict what possible types can be used to construct a monad instance. That would be discrimination, and you must agree to accept all comers.

Simple, no? Apparently not...

Other things have nothing to do with monads per se gunk up the descriptions about monads:

One red herring (the nuclear waste metaphor) refers to the fact since monads may or may not have an escape-clause (called variously runXXX, evalXXX, unsafePerformXXX), and IO in particular does not. The presence or absence of this has *nothing* to do with monads (only with IO), participates in no monadic laws, and shouldn't even be in the chapter on Monads. Whether nuclear waste seeps in (as in a State monad) or stays out (IO monad) has nothing to do with their monadic property and is a special property of those particular classes.

Another even redder herring is the dreaded sequencing aspect. Monads do sequence *denotationally*, the way any nested closures sequence, which is exactly *backwards* from the naive understanding of sequencing: symbols defined to the left are in the *inner* scope, those to the right are in the *outer* scope. Perversely, when the symbols are evaluated, the rightmost monad is evaluated first. The leftmost monad in the program, the IO () passed in by main, is the *last* thing to be evaluated, not the first. The outermost monad (rightmost bound function) is in the driver seat, and is absolutely free to ignore the monad to its left (which in turn encloses monads to its left)! This includes of course the main input IO () monad. Don't believe me?

Prelude> const 3 (return "Nuclear waste leaking..." >>= print) + 5 8

Phew, no nuclear waste leaked after all. What a relief!

This sequencing then has nothing to do with *operational* sequencing. When the symbols are evaluated is the basic call-by-need data-dependent stuff of most Haskell symbols and again, has nothing to do with monads.

I learned about the IO monad first and I regret it bitterly. It cost me a years' worth of misunderstanding. I misapprehended that a monad had something to do with nuclear waste and never escaping the single-threadedness. I hope the new O'Reilly book doesn't make that mistake. Teach IO right away, but just don't call it a monad. IO is the exception, not the rule, in the menagerie of Haskell monads.

How does all this map to C++? A monad is a a class, with no useful interface for the end user, that looks roughly (i.e. I haven't tested it) like:

template class Monad { public:

virtual ~Monad() {}

// return Monad(T t) : t_(t) {}

// bind operator (>>=), where // F :: Monad -> (T -> Monad) -> Monad virtual template <class U> Monad operator>>(typename U::F f) = 0;

private: T t_; };

C++ programmers will immediately see past the syntactic kruft to notice that 1) the constructor arg is not a value but an unevaluated function object, that starts out unevaluated. 2) The result of m >> f is a monad object, totally unevaluated. 3) There is no member function to do anything with the monad at all! As is, it is useless.

Derivers of this class will naturally want to add such functionality:

template class MyMonad : public Monad { // The parent class needs to know what type of monad // this can bind to typedef someUnaryFunctionObjectTypeReturningB F;

// There is no input, just an output! // The input is via the constructor arg of the innermost monad B operator()() { ... start the ball rolling ... } };

Non-C++ programmers will be stunned that the above garbage can be understood by anyone, compared to the simplicity of type classes in Haskell. When all you have is a hammer...

The moral of the story is that monads are less than meets the eye. You can create them and concatenate them, but may not be able to do anything with them (some monads do let you, some don't), though the runtime system agrees to evaluate one special monad exactly once.

What the rightmost monad does with its internals (including all inner/left monads bound to it) has nothing to do with monads whatever, except for the minimal requirement that they agree to be bound only to other monads like themselves, and that as a group they all agree to not form a clique (i.e. they are associative).

What could be simpler that that? No please, no more nuclear waste! :)

Dan

peterv wrote:

...

Kaveh> "A monad is like a loop that can run a new function against its variable in each iteration." I’m an imperative programmer learning Haskell, so I’m a newbie, but I’ll give it a try ☺ Making mistakes is the best way to learn it ;)

There are lots of different kinds of monads, but let’s stick to the IO monad first, which you seem to refer to.

No *an IO monad is not a loop at all*. Instead, from an imperative programmer’s point of view, the following might be better:

“an IO monad is a delayed action that will be executed as soon as that action is needed for further evaluation of the program.”

The simple program

main = getLine >>= putStrLn can be visually represented as (see attachment)

The “world” (=a representation of your computer’s hardware) is passed to the main function, which passes it to all actions that it encounters during its lazy evaluation, causing the executing of the actions as an effect. The red wire through which the “world flows” is a “single thread”, it cannot be split (because the physical world cannot be copied!!!), so no unwanted side effects can ever occur, making IO safe in Haskell. When you write your IO program, this world object is never available (the IO type is a special internal type), so the red wire is erased from the diagram, and the getLine and putStrLn boxes become “delayed actions”. Imperative programmers like myself might initially be confused when they see Haskell’s do notation, because it looks like the actions are strict statements as in C/C++/Pascal/Java/C#/etc, but they are not.

For example, try the following program:

main = do last [ putStrLn "NOT executed although it is first in the list, as it is not used by the main function!", putStrLn "This action IS executed because it is evaluated by the main function." ]

This is of course all due to Haskell’s laziness which only evaluates just those expressions that it needs to evaluate the main function.

One thing to note in the diagram above is that the getLine box has TWO outputs, the String and the World. But functions can only have a single output, but this can be tuple. Hence the passing of the world from one box to the other is a bit more complicated. It is this pattern of extracting both values from the output and passing them to the next function and other related combinations that form the generic monad class, which can be used for many more things than IO.

See http://haskell.org/haskellwiki/IO_inside for a much deeper and more correct explanation ☺

And for the pros here, did this newbie make any sense? Probably not ;-) Oh no, yet another monad explanation!!! Now the universe will most certainly collapse…

No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 31/07/2007 17:26

------------------------------------------------------------------------

------------------------------------------------------------------------

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

Hello,

'Monad' is a type class.

So what's 'IO'? Is the correct terminology 'instance' as in 'IO is an instance of Monad'. I consider 'IO' to be 'a monad' as that fits with mathematical terminology.

I agree with this.

But what about an actual object of type 'IO Int', say?

I usually describe the type resulting from applying a monad a computation. Then 'IO Int' would be something like an IO computation of an Int. This terminology also jibes well with, or rather comes from, Moggi's computational lambda calculus (one of the early papers showing uses of Monads to computer science). -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

I knew someone was going to catch me wandering into the deep end of the pool! Having read large parts of your blog, I would never presume to tell you anything about Haskell or category theory, but what the hell...

I mostly sympathise with your rant, but I think you need to be clearer about what exactly is concatenated. In general you can't concatenate Monads. What you *can* concatenate are Kleisli arrows (ie. things of type Monad m => a -> m b). You can also apply Kleisli arrows to Monads, and that's what >>= does.

I feel that talking about Monads without Kleisli arrows is like talking about category theory without arrows, or at least sets without functions. In each case, without the latter, the former is more or less useless.

OK, I'll be clearer. I did actually mean Kleisli arrows, though I disagree about your statement about concatenating monad instances and claims of "useless": Prelude> print "Hello" >> return 3 "Hello" 3 Granted, >> is not as "general" as >>=, so combining one monad instance with another is not as "general" as with a Kleisli arrow: concatenating degenerates to simple sequencing. Sequencing print statements is more rather than less useless to many people, but I see your point. Actually, you have made my point! :) The forgetful action of Kleisli arrows acting on a monad (or conversely the free algebra of a monad as a subspace of Kleisli arrows) is to my understanding intimately connected with the specialness of the IO monad. It is the continuous nature of Haskell monads that gives non-IO monads value. So I guess my rant really was about Kleisli arrows not all being forgetful functors, used only for their sequencing effect. It just sounded too hard to pull that argument off without reinforcing the myth that you need to know category theory to have a rant about Haskell tutorials.

Also, I'm having a terminological difficulty that maybe someone can help with:

'Monad' is a type class.

Actually I thought it was a type class constructor. The monad Monad m => m a is continuous in its instance type a, which is important in establishing the relationship between >>= and >>. The Haskell type 'IO ()' is a monad instance that is also isomorphic to the discrete trivial monad, but that is not a Haskell Monad capital-M. I used the term "instance" because the type IO () is an instance of the typeclass IO, not for any more profound reason. Forgive the display of wanton ignorance above. After all, isn't that what ranting is all about? Dan Weston Dan Piponi wrote:

On 8/1/07, Dan Weston wrote:

...

The moral of the story is that monads are less than meets the eye. You can create them and concatenate them

I mostly sympathise with your rant, but I think you need to be clearer about what exactly is concatenated. In general you can't concatenate Monads. What you *can* concatenate are Kleisli arrows (ie. things of type Monad m => a -> m b). You can also apply Kleisli arrows to Monads, and that's what >>= does.

I feel that talking about Monads without Kleisli arrows is like talking about category theory without arrows, or at least sets without functions. In each case, without the latter, the former is more or less useless.

Also, I'm having a terminological difficulty that maybe someone can help with:

'Monad' is a type class.

So what's 'IO'? Is the correct terminology 'instance' as in 'IO is an instance of Monad'. I consider 'IO' to be 'a monad' as that fits with mathematical terminology. But what about an actual object of type 'IO Int', say? Some people have been loosely calling such an object 'a monad'. That doesn't seem quite right. Maybe it's 'an instance of IO Int', though that's stretching the word 'instance' to meaning two different things. And if an object of type IO Int is in instance of IO Int, is it reasonable to also call it an 'instance of IO', or even 'an instance of Monad'? I'm sure there are proper words for all these things if someone fills me in. -- Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

a Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules. the Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. the monadic interface gives you two operations, one to throw things into a monad thing (return), and one to chain two monad things together (>>=). the chaining explicitly caters for information flowing from the first to the second parameter of (>>=). the monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the structure of chaining is irrelevant, only the ordering of chained monad things matters. there are usually other ways to create 'primitive' monadic things, which can be combined into complex monadic structures using the operations from the Monad interface. there is usually a way to interpret monadic structures built in this way (a 'run' operation of some kind). that's it, i think?-) claus examples include: - i/o: primitive monadic things are basic i/o operations, the 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO monad structures sequentially, starting with the leftmost innermost i/o operation in the structure and applying the second argument of (>>=) to the result of executing the first. - []: primitive monadic things are lists, the 'run' operation is the identity, ie, the lists are directly exposed as data structures, return creates a singleton list, (>>=) applies its second argument to each element of its first argument and concatenates the results (concatMap). - State: primitive monadic things are operations on a state type, returning a result and a state; return returns its parameter, passing its input state unchanged, (>>=) applies its first parameter to the input state, applies its second parameter to the result value and result state of the first. 'run' is runState and applies a (possibly) complex monadic thing to an input state, returning a result and a (modified) state.

On 2 Aug 2007, at 1:20 pm, Alexis Hazell wrote:

Category theorists can define monads concisely using the language of their discipline - surely we can settle on a definition of Haskell Monads that would make sense to any programmer who has mastered basic programming concepts?

It all depends on what you mean "make sense to". I can tell my student that (an instance of Monad) is a type constructor applications of which support certain operations that must satisfy certain operations. They can memorise that. But it remains meaningless noise to them. What matters is not what monads *ARE* but what they are *FOR*. Why should anyone care what monads are until they know why monads matter? One of my colleagues here, who has worked in logic for many years, is fond of saying that there are "set theory" people who like to have their feet on the ground and "category theory" people who like to have their heads in the air. There's no dispute that you get a much better view with your head in the air; there is no dispute that the general definitions and understandings of monads have power and utility. Me, I'm a set theory person. I have no trouble with fields, got my head around tensors and Lie groups (or very nearly), and I even know what a fibre bundle is (got an A for that). All of this is *grounded*. But I have repeatedly hit category theory and as repeatedly bounced. Chapter 1? No trouble. Chapter 2? No trouble. Chapter 3? Bounce. If a "category theory" person wants to understand monads, they will be happy with an abstract approach and work down from there. But if a "set theory" person wants to understand monads, they have to start with simple specific cases. The IO monad first. The ST monad. Then perhaps Maybe and []. And then start learning about monad transformers. The understanding of monads as such will grow out of this; by the time they are ready to cope with these compact high level definitions people are talking about they won't need it any more. I don't have any numbers. It would be interesting if someone did a survey. But I suspect that "category theory" people are a minority even among functional programmers. How many O'Caml programmers worry about the definition of monads? So go on arguing about how to define monads for Haskell, but consider your audience.

On 02/08/07, Alexis Hazell wrote:

It's at this point that i feel there's an issue. Haskell Monads are used FOR many many things. And rather than get to the core of what a Monad is, many people provide two or three motivating examples - examples which merely serve to show /some/ of what Monads are about, but which will lead astray any person who incorrectly assumes that these two or three examples constitute the totality of the Monadic universe, and who makes inferences about Monads accordingly. (To me, the notion that a Monad is merely a kind of loop is an example of this.)

I agree with this very much. Monads are used for a great deal of things, some of which seem related (IO/State, []/Maybe) while others are utterly disconnected. Simon Peyton Jones has jokingly said that "warm fuzzy things" would have been a better choice of name. In seriousness, though, I think the exact name is not the problem. I would suggest that *having a name* is the problem. In imperative programming there are many idioms we would recognise. Take the "do something to an array" idiom: for (int i = 0; i < arr.length; i++) { arr[i] = foo(arr[i]); } This is a pretty obvious pattern. Some might say it's so obvious that it doesn't need a name. Yet we've got one in functional programming because we can. Without higher-order functions it's not possible to encapsulate and name such common idioms. It seems a bit superfluous to name something if you can't do anything with the name. But with higher-order functions we *can* encapsulate these ideas, and that means we *must* name them. Add to that the insatiable mathematical desire to abstract, abstract, abstract... Intuitively it seems that monads are similar, except the instances are much less obviously connected. It's easy to see the connection between State and IO. But those two to []? Do I have an suggestions? Well, maybe the right way would be to do as we do with map and fold, etc: show the explicitly recursive example, then generalise. So, show how we could we would thread state in Haskell, or how we would do optional (Maybe-style) values, then generalise, *slowly* coalescing the more similar monads first before reaching the 'top' of the monadic phylogenetic tree. Hmm, I can see that previous paragraph is not as clear as it could be. But anyway: has anyone used this approach before? Cheers, D.

IMHO although this is a great explanation of what a monad is (as far as I understand it), for newbies I think it helps a lot to first look at the specific cases where monads are used and why they are invented, as explained in http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html and then looking at http://haskell.org/haskellwiki/IO_inside for the IO thingy. However, one thing which I find annoying is that a "classic pure" function cannot evaluate an IO function unless you use unsafePerformIO; one must "promote" (?demote) the pure function into the IO monad. For example, as an exercise I tried to convert the Monte Carlo experiment as demonstrated in http://mitpress.mit.edu/sicp/full-text/sicp/book/node53.html into Haskell (warning: newbie code ahead, should be much nicer when I once become a real Haskeller in a million years ;-) In the code below I had to change the monteCarlo1 into a completely different monteCarlo2 in order to use the IO random facility. Okay, this is "expected behavior", but for an imperative programmer, this is quite a shock! Any ways of "promoting" such a pure function into the monadic one automatically? I tried playing with "liftM", without succes. import Data.Ratio import Data.List import System.Random import Control.Monad -- Monte Carlo using "pure" functions monteCarlo1 :: Integral n => n -> (a -> (a,Bool)) -> a -> Ratio n monteCarlo1 trials experiment startValue = trialsPassed % trials where trialsPassed = genericLength $ filter id outcomes outcomes = snd $ unzip $ genericTake trials $ iterate (experiment . fst) (experiment startValue) cesaroTest1 :: StdGen -> (StdGen, Bool) cesaroTest1 gen0 = (gen2, (gcd rand1 rand2) == 1) where (rand1, gen1) = random gen0 (rand2, gen2) = random gen1 estimatePi1 trials = sqrt $ 6 / (fromRational $ monteCarlo1 trials cesaroTest1 (mkStdGen 0)) -- Monte Carlo using monadic IO -- no genericReplicateM, so must use Int monteCarlo2 :: Int -> IO Bool -> IO (Ratio Integer) monteCarlo2 trials experiment = do outcomes <- replicateM trials experiment return $ fromIntegral (genericLength $ filter id outcomes) % fromIntegral trials cesaroTest2 = do rand1 <- getStdRandom random rand2 <- getStdRandom random return $ (gcd rand1 rand2) == 1 estimatePi2 trials = do mc <- monteCarlo2 trials cesaroTest2 return $ sqrt $ 6 / (fromRational mc) main = let pi1 = estimatePi1 50000 in do pi2 <- estimatePi2 50000 putStrLn (show pi1) >> putStrLn (show pi2) -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Claus Reinke Sent: Thursday, August 02, 2007 12:18 AM To: haskell-cafe@haskell.org Subject: Re: FW: RE [Haskell-cafe] Monad Description For Imperative Programmer a Monad is a type constructor with two operations, implementing a standard interface and following a few simple rules. the Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. the monadic interface gives you two operations, one to throw things into a monad thing (return), and one to chain two monad things together (>>=). the chaining explicitly caters for information flowing from the first to the second parameter of (>>=). the monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the structure of chaining is irrelevant, only the ordering of chained monad things matters. there are usually other ways to create 'primitive' monadic things, which can be combined into complex monadic structures using the operations from the Monad interface. there is usually a way to interpret monadic structures built in this way (a 'run' operation of some kind). that's it, i think?-) claus examples include: - i/o: primitive monadic things are basic i/o operations, the 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO monad structures sequentially, starting with the leftmost innermost i/o operation in the structure and applying the second argument of (>>=) to the result of executing the first. - []: primitive monadic things are lists, the 'run' operation is the identity, ie, the lists are directly exposed as data structures, return creates a singleton list, (>>=) applies its second argument to each element of its first argument and concatenates the results (concatMap). - State: primitive monadic things are operations on a state type, returning a result and a state; return returns its parameter, passing its input state unchanged, (>>=) applies its first parameter to the input state, applies its second parameter to the result value and result state of the first. 'run' is runState and applies a (possibly) complex monadic thing to an input state, returning a result and a (modified) state. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Claus Reinke wrote:

there is usually a way to interpret monadic structures built in this way (a 'run' operation of some kind).

The "run" operation of type (m a -> a) is the (comonadic) coreturn. Many monads are almost comonads too, for a meaning of "almost" to be made precise. Claus Reinke wrote:

- i/o: primitive monadic things are basic i/o operations, the 'run' operation is outside the language, applied to 'Main.main', and interprets (abstract) IO monad structures sequentially, starting with the leftmost innermost i/o operation in the structure and applying the second argument of (>>=) to the result of executing the first.

"Run" for IO monad is obviously unsafePerformIO :: IO a -> a. Claus Reinke wrote:

- []: primitive monadic things are lists, the 'run' operation is the identity, ie, the lists are directly exposed as data structures, return creates a singleton list, (>>=) applies its second argument to each element of its first argument and concatenates the results (concatMap).

"Run" for [] is almost head :: [a] -> a. For the type of infinite streams, the research community's comonad de rigeur, coreturn _is_ h(ea)d. Claus Reinke wrote:

- State: primitive monadic things are operations on a state type, returning a result and a state; return returns its parameter, passing its input state unchanged, (>>=) applies its first parameter to the input state, applies its second parameter to the result value and result state of the first. 'run' is runState and applies a (possibly) complex monadic thing to an input state, returning a result and a (modified) state.

The State monad is almost (there's that word again!) like the Context comonad. And the Context comonad is a comonadification of the suboptimally named Reader monad, a comonadification that wants to be made precise. In fact, there's another comonad that solves the analogical equation: comonad x is to monad State as comonad Context is to monad Reader. Any takers on calling x the Costate comonad and Reader the Ntext monad? -- View this message in context: http://www.nabble.com/FW%3A-RE-Monad-Description-For-Imperative-Programmer-t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.