Re: [Haskell-cafe] Monad explanation

Richard O'Keefe wrote: Gregg Reynolds wrote: > Sure, you can treat a morphism as an object, but only by moving to a > higher (or different) level of abstraction. False as a generalisation about mathematics. False about functional programming languages, the very essence of which is treating f

Re: [Haskell-cafe] Monad explanation

On 10/02/2009, at 4:45 AM, Tillmann Rendel wrote: A Haskell runtime system is a somewhat vaguely specified interpreter for (IO a) values. While it would be nice to a have a better specification of that interpreter, it is not part of the semantics of the language Haskell. While not "offi

Re: [Haskell-cafe] Monad explanation

On 9 Feb 2009, at 9:56 pm, Gregg Reynolds wrote: Here's an analogy that will make the logical contradiction clear. Forget computers and assume you have been asked to referee a paper containing a proof with the following passage: Let x = ___ (Please fill in the blank) I think you will a

Re: [Haskell-cafe] Monad explanation

On 10 Feb 2009, at 12:24 am, Gregg Reynolds wrote: My bad, I restate: a value cannot be both static and dynamic. It's not clear what you mean here, but in what sense are "static" values not a subset of "dynamic" ones? Or an object and a morphism. Crack open any book on category theory a

Re: [Haskell-cafe] Monad explanation

Hi Gregg, Gregg Reynolds wrote: Right; "implementation of IO" means also an implementation for >>=, not just the IO operators. I hadn't thought about that but it's hugely important for the exposition of monads and IO. Indeed, that's very important. Note that the topics "monads in Haskell" an

Re: [Haskell-cafe] Monad explanation

2009/2/9 Gregg Reynolds : > > Right; "implementation of IO" means also an implementation for >>=, not just > the IO operators. I hadn't thought about that but it's hugely important for > the exposition of monads and IO. > > "The IO Char indicates that getChar, when invoked, performs some action >

Re: [Haskell-cafe] Monad explanation

On Mon, Feb 9, 2009 at 5:32 AM, Sittampalam, Ganesh < ganesh.sittampa...@credit-suisse.com> wrote: > > > My bad, I restate: a value cannot be both static and dynamic. Or an > > object and a morphism. Or an element and a function. Sure, you can > > treat a morphism as an object, but only by mov

RE: [Haskell-cafe] Monad explanation

> My bad, I restate: a value cannot be both static and dynamic. Or an > object and a morphism. Or an element and a function. Sure, you can > treat a morphism as an object, but only by moving to a higher (or > different) level of abstraction. That doesn't erase the difference > between object

Re: [Haskell-cafe] Monad explanation

Huh? The getChar function does yield a value of type (IO Char), exactly as the type signature says. If you want access to the Char you must use a >>=, just like in any other monad. 2009/2/9 Gregg Reynolds : > On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris wrote: >> >> -BEGIN PGP SIGNED MESSAGE-

Re: [Haskell-cafe] Monad explanation

On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I also agree it is a value. > The original post was attempting to make a distinction that does not > exist. I deliberately avoided that topic. > > "A thing cannot be both a value and a functio

Re: [Haskell-cafe] Monad explanation

Sorry, I should have come down on the original poster too. ;) Functions are values, after all. On Mon, Feb 9, 2009 at 10:38 AM, Tony Morris wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I also agree it is a value. > The original post was attempting to make a distinction that does n

Re: [Haskell-cafe] Monad explanation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I also agree it is a value. The original post was attempting to make a distinction that does not exist. I deliberately avoided that topic. "A thing cannot be both a value and a function, but e,g, getChar" My original intent was to hope the poster rec

Re: [Haskell-cafe] Monad explanation

But an (IO Char) is a value. You can do all the things with it that you can do with values, e.g., pass it as an argument, stick it in a list, etc. It is a special kind of value, since if it ever "gets in contact with" the top level it will be executed. But the fact that IO types also behave as va

Re: [Haskell-cafe] Monad explanation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You're right - my statement is inaccurate. Implementation details aside, I am referring specifically to the statement "getChar ... has the type signature of a value". It clearly does not. Lennart Augustsson wrote: > Not it doesn't. getChar has the t

Re: [Haskell-cafe] Monad explanation

Not it doesn't. getChar has the type signature IO Char. The IO type is abstract. GHC happens to implement it by a state monad. But in, e.g., hbc it is implemented in a totally different way, more like a continuation monad. Peeking inside an implementation of IO can be illuminating, but one must

Re: [Haskell-cafe] Monad explanation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregg Reynolds wrote: > The point being that the metalanguage commonly used to describe IO > in Haskell contains a logical contradiction. A thing cannot be both > a value and a function, but e,g, getChar behaves like a function and > has the type sign

Re: [Haskell-cafe] Monad explanation

On Sun, Feb 8, 2009 at 6:39 PM, Richard O'Keefe wrote: > > is a good one. If you want to say that "a mathematical value with > a non-mathematical effect" is nonsensical, more power to you. I said > I don't want to get far into White Knight territory. As long as you > can agree "A mathematical

Re: [Haskell-cafe] Monad explanation

On 6 Feb 2009, at 5:08 am, Gregg Reynolds wrote: Not "programs", but "programs that do IO". The point of the idiom is that there's an external side effect involved. What sticks in my craw is that "a mathematical value with a non-mathematical side effect" is, well, non-mathematical and pos

Re: [Haskell-cafe] Monad explanation

Tim Newsham wrote: > The only difference with IO then is that to get IO programs to run, > you have > to do it inside another IO program. Almost. Add to your mental model a "runIO" that is invoked when your program runs as: "runIO main". Your haskell compiler or interpretter arranges this

Re: [Haskell-cafe] Monad explanation

So if IO represents a program that when executed interacts with the world's state, is it safe to say that when I return (State Int Int), that I'm returning a "State program"? That'd make sense as it really does look like we force the State to be evaluated with runState, evalState or execState.

Re: [Haskell-cafe] Monad explanation

On Thu, 2009-02-05 at 15:52 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > > wrot

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast wrote: > On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > > wrote: > > > > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > > > >

Re: [Haskell-cafe] Monad explanation

On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > wro

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast wrote: > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > wrote: > > I think the point of the Monad is that it > > works as a conta

Re: [Haskell-cafe] Monad explanation

On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > wrote: > I think the point of the Monad is that it > works as a container of stuff, that still > allows mathemat

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 12:25 PM, Andrew Wagner wrote: > On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach wrote: > >> >> Well all I can tell you is that I can have (IO Int) in a function as a >> return, and the function is not idempotent in terms of the "stuff" inside IO >> being the same. >> >> Sou

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach wrote: > > Well all I can tell you is that I can have (IO Int) in a function as a > return, and the function is not idempotent in terms of the "stuff" inside IO > being the same. > > Sounds impure to me. > Right, thus IO is impure. but as long as th

Re: [Haskell-cafe] Monad explanation

You are absolutely right. The statement "The values of the IO monad are programs that do IO. " is somewhat nonsensical. Values don't do anything, they just are. But values of the IO monad *describe* how to do IO; they can be seen as a recipe for doing IO. A recipe doesn't cook a dish, but when t

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner wrote: > I think the point of the Monad is that it works as a container of stuff, >>> that still allows mathematically pure things to happen, while possibly >>> having some opaque "other stuff" going on. >>> >> > This at least sounds, very wrong, eve

Re: [Haskell-cafe] Monad explanation

On Thu, 2009-02-05 at 20:46 +0100, Lennart Augustsson wrote: > You are absolutely right. The statement > "The values of the IO monad are programs that do IO. " > is somewhat nonsensical. Values don't do anything, they just are. Technically, programs don't do anything either. I think of values

Re: [Haskell-cafe] Monad explanation

On Thu, Feb 5, 2009 at 1:46 PM, Lennart Augustsson wrote: > You are absolutely right. The statement > "The values of the IO monad are programs that do IO. " > is somewhat nonsensical. Values don't do anything, they just are. Whew! So I'm not crazy. I was starting to wonder. > But values of t

Re: [Haskell-cafe] Monad explanation

You are absolutely right. The statement "The values of the IO monad are programs that do IO. " is somewhat nonsensical. Values don't do anything, they just are. But values of the IO monad *describe* how to do IO; they can be seen as a recipe for doing IO. A recipe doesn't cook a dish, but when t

Re: [Haskell-cafe] Monad explanation

Ahem... WHAT??? IO monad is impure??? What do you mean? On 5 Feb 2009, at 22:25, Andrew Wagner wrote: I think the point of the Monad is that it works as a container of stuff, that still allows mathematically pure things to happen, while possibly having some opaque "other stuff" going on.

Re: [Haskell-cafe] Monad explanation

> > I think the point of the Monad is that it works as a container of stuff, >> that still allows mathematically pure things to happen, while possibly >> having some opaque "other stuff" going on. >> > This at least sounds, very wrong, even if it's not. Monads are not impure. IO is, but it's only

Re: [Haskell-cafe] Monad explanation

2009/2/5 Gregg Reynolds > On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe wrote: > >> >> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: >> >>> That's a fairly common representation, seems to work for lots of people, >>> but it caused me no end of trouble. Values are mathematical objects; how

Re: [Haskell-cafe] Monad explanation

On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe wrote: > > On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: > >> That's a fairly common representation, seems to work for lots of people, >> but it caused me no end of trouble. Values are mathematical objects; how, I >> asked myself, can they poss

Re: [Haskell-cafe] Monad explanation

On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: That's a fairly common representation, seems to work for lots of people, but it caused me no end of trouble. Values are mathematical objects; how, I asked myself, can they possibly /be/ programs that do IO (or actions, or computations, or )

Re: [Haskell-cafe] Monad explanation

On Wed, 2009-02-04 at 23:55 +0200, Tymur Porkuian wrote: > > Huh? You can't actually over-ride function application --- Haskell's > > built-in application always does exactly the same thing, at every type. > It's a metaphor. Oh, right. That one word that means `inaccurate way of putting things'

Re: [Haskell-cafe] Monad explanation

> x `fmap` f disregard that, f `fmap` x ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

> It's a metaphor. In every case container has its own method of > applying functions to its contents - e.g. instead of "f x" we write "x > fmap f". x `fmap` f, of course ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailm

Re: [Haskell-cafe] Monad explanation

> Huh? You can't actually over-ride function application --- Haskell's > built-in application always does exactly the same thing, at every type. It's a metaphor. In every case container has its own method of applying functions to its contents - e.g. instead of "f x" we write "x fmap f". > You ca

Re: [Haskell-cafe] Monad explanation

On Wed, 2009-02-04 at 23:13 +0200, Tymur Porkuian wrote: > Actually, I understand these types in terms of containers that > override standard method of function application for their contents. Huh? You can't actually over-ride function application --- Haskell's built-in application always does ex

Re: [Haskell-cafe] Monad explanation

On Wed, Feb 4, 2009 at 11:41 AM, Tim Newsham wrote: > I put up a small Monad explanation (I wouldn't quite call it > a tutorial): > > http://www.thenewsh.com/~newsham/haskell/monad.html > "The values of the IO monad are programs that do IO

Re: [Haskell-cafe] Monad explanation

Actually, I understand these types in terms of containers that override standard method of function application for their contents. In fact, there may be no contents, or several items, or nothing at all, or something strange, but the container behaves like there is a value of some type inside it.

Re: [Haskell-cafe] Monad explanation

On Wed, 2009-02-04 at 22:16 +0200, Tymur Porkuian wrote: > For me, the key to understanding monads was that monad is "a value > that know how to apply functions to itself". Or, more correctly, a > container that knows how to apply functions to whatever is inside it. Close. (Monads are not `values

Re: [Haskell-cafe] Monad explanation

On Wed, Feb 4, 2009 at 12:16 PM, Tymur Porkuian wrote: > For me, the key to understanding monads was that monad is "a value > that know how to apply functions to itself". Or, more correctly, a > container that knows how to apply functions to whatever is inside it. You've just described a Functor

Re: [Haskell-cafe] Monad explanation

For me, the key to understanding monads was that monad is "a value that know how to apply functions to itself". Or, more correctly, a container that knows how to apply functions to whatever is inside it. Before understanding this I read a lot of tutorials that presented monads as computations, IO s

Re: [Haskell-cafe] Monad explanation

For me, the key to understanding monads was that monad is "a value that know how to apply functions to itself". Or, more correctly, a container that knows how to apply functions to whatever is inside it. Before understanding this I read a lot of tutorials that presented monads as computations, IO s

Re: [Haskell-cafe] Monad explanation

This is nice and simple. My only concern is I'm not sure there's enough of a distinction between "Monad" and "State Monad". That is, I'm not sure it's clear enough that the way you're binding the small programs together in the initial example is only one way you could bind them together, and thus i

[Haskell-cafe] Monad explanation

I put up a small Monad explanation (I wouldn't quite call it a tutorial): http://www.thenewsh.com/~newsham/haskell/monad.html The intent here is to is to have a short description of what a Monad is that is approachable by Haskell beginners or non- Haskell programmers who are looking for an intu