Re: [Haskell-cafe] Explaining monads

Paul Hudak wrote: > > [I]n the one-of-many ways that I view monads, a monad is just a high-order > function that abstracts away function composition. In particular, if I > have an action f, and an action g, I can think of them as recipes, because > I can combine them via f >>= g. It's only aft

Re: [Haskell-cafe] Explaining monads

I've seen the analogy with "recipes" used before, but I think that you need to be careful when you try to distinguish the analogy to monads from the analogy to functions. The reason is that, in the one-of-many ways that I view monads, a monad is just a high-order /function /that abstracts away

Re: [Haskell-cafe] Explaining monads

On Tue, Aug 14, 2007 at 05:53:05PM -0700, Michael Vanier wrote: > > For what it's worth, the nature of Haskell is such that you do (at > least currently) have to spend a lot of time reading research papers > to understand what's going on. Maybe that will change sometime, but > probably not soon.

Re: [Haskell-cafe] Explaining monads

For what it's worth, the nature of Haskell is such that you do (at least currently) have to spend a lot of time reading research papers to understand what's going on. Maybe that will change sometime, but probably not soon. This ties in to the open-endedness of Haskell; I sometimes think that re

Re: [Haskell-cafe] Explaining monads

On Tue, 2007-08-14 at 12:40 -0500, Lanny Ripple wrote: > Derek Elkins wrote: > > What people need to do is stop reading two page blog posts by someone > > who's "just got" monads and read the well-written peer-reviewed papers > > I have taught many people to program in group settings and > indivi

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Seth Gordon <[EMAIL PROTECTED]> wrote: > Sebastian Sylvan wrote: > > On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > >> If I was one of your students and you said that monads are recipes I > >> would immediately ask you where the monads are in my factorial program > >> regardless

Re: [Haskell-cafe] Explaining monads

Sebastian Sylvan wrote: On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: If I was one of your students and you said that monads are recipes I would immediately ask you where the monads are in my factorial program regardless of whether you had introduced one or two different analogies for recip

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Malte Milatz <[EMAIL PROTECTED]> wrote: > Dan Piponi, Tue, 14 Aug 2007 11:52:16 -0700: > > All functions can be viewed as recipes. (+) is a recipe. Give me some > > ingredients (two numbers) and I'll use (+) to give you back their sum. > > (+) is not a recipe, it is a chef. On the othe

Re: [Haskell-cafe] Explaining monads

Dan Piponi, Tue, 14 Aug 2007 11:52:16 -0700: > All functions can be viewed as recipes. (+) is a recipe. Give me some > ingredients (two numbers) and I'll use (+) to give you back their sum. (+) is not a recipe, it is a chef. On the other hand, (return 5 :: State Integer) is a recipe. You need a c

Re: [Haskell-cafe] Explaining monads

Dan Piponi wrote: | On 8/14/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote: | > You don't normally call x::Int a computation of an Int because there's | > nothing that distinguishes the value of the x from what it was before | > you computed it. | | Can you spell out exactly what you mean by th

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > Well that's easy, don't use the recipe analogy to explain code, use it > > for monadic values exclusively, and you avoid the confusion entirely! > > > > I don't think it's that complicat

Re: [Haskell-cafe] Explaining monads

Hello, > On 14/08/07, Jeff Polakow <[EMAIL PROTECTED]> wrote: > Of course, the type [Int] denotes a value which is a list of Ints; > additionally [Int] can be viewed as a value representing the > nondeterministic computation of a single Int. Generally, the type > Monad m => m Int can be viewed

Re: [Haskell-cafe] Explaining monads

On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > Well that's easy, don't use the recipe analogy to explain code, use it > for monadic values exclusively, and you avoid the confusion entirely! > > I don't think it's that complicated. It certainly is complicated. I think I have a good grasp

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > > > Where do monads come in? > > > > Well I would try to distinguish between code that we write to compute > > values, and values whi

Re: [Haskell-cafe] Explaining monads

On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > > Where do monads come in? > > Well I would try to distinguish between code that we write to compute > values, and values which represent monadic actions when coming up with > analogies.

Re: [Haskell-cafe] Explaining monads

On 8/14/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote: > You don't normally call x::Int a computation of an Int because there's > nothing that distinguishes the value of the x from what it was before you > computed it. Can you spell out exactly what you mean by this? > So I prefer to regard x

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Jeff Polakow <[EMAIL PROTECTED]> wrote: > > Of course, the type [Int] denotes a value which is a list of Ints; > additionally [Int] can be viewed as a value representing the > nondeterministic computation of a single Int. Generally, the type Monad m => > m Int can be viewed as a value

Re: [Haskell-cafe] Explaining monads

Hello, > On 8/14/07, Jeff Polakow <[EMAIL PROTECTED]> wrote: > > One general intuition about monads is that they represent computations > > rather than simple (already computed) values: > > > x :: Int -- x is an Int > > x :: Monad m => m Int -- x is a computation of an Int

Re: [Haskell-cafe] Explaining monads

Derek Elkins wrote: What people need to do is stop reading two page blog posts by someone who's "just got" monads and read the well-written peer-reviewed papers I have taught many people to program in group settings and individually in my career. I have referred them to many tutorials. I h

Re: [Haskell-cafe] Explaining monads

You don't normally call x::Int a computation of an Int because there's nothing that distinguishes the value of the x from what it was before you computed it. So I prefer to regard x as a value (in a domain, of course). But for x :: (Monad m) => m Int there is something else happening, so the word

Re: [Haskell-cafe] Explaining monads

A very good point. I even knew that implicitly but wasn't thinking in those terms explicitly when writing up my first post and it does make a difference in how you view things. -ljr Jeff Polakow wrote: Hello, > Look! You are doing it again! :) Does that paragraph even > contain the

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > I like the very light weight analogy (which works for most practical > > uses of monads) that a monadic action is a "recipe" > > Many introductory programming books present the idea of a

Re: [Haskell-cafe] Explaining monads

On Tue, 2007-08-14 at 09:55 -0500, Lanny Ripple wrote: > Having just gone through all the tutorials and things (again but > this time I think it stuck) the Haskell community is on the wrong > track as far as teaching Monads to new programmers. > > If I were teaching addition and multiplication t

Re: [Haskell-cafe] Explaining monads

Hello, > Look! You are doing it again! :) Does that paragraph even > contain the word "Monad"? :) > Sorry. Your first paragraph led me to believe you were writing about monads. > I'm aware a monad is an abstraction and as such it doesn't *do* > anything. My point was along the lines that

Re: [Haskell-cafe] Explaining monads

On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > I like the very light weight analogy (which works for most practical > uses of monads) that a monadic action is a "recipe" Many introductory programming books present the idea of a program as a recipe. Here's a recipe for computing factoria

Re: [Haskell-cafe] Explaining monads

On 8/14/07, Jeff Polakow <[EMAIL PROTECTED]> wrote: > One general intuition about monads is that they represent computations > rather than simple (already computed) values: > x :: Int -- x is an Int > x :: Monad m => m Int -- x is a computation of an Int What's a "computati

Re: [Haskell-cafe] Explaining monads

Hallo, On 8/14/07, Jeff Polakow <[EMAIL PROTECTED]> wrote: > > Hello, > > There is clearly a problem with the Haskell/monad tutorials out there... > > > The tutorials seriously need to step back and start with > > something like, "To enforce order of evaluation we evaluate > > closures* returnin

Re: [Haskell-cafe] Explaining monads

Look! You are doing it again! :) Does that paragraph even contain the word "Monad"? :) I'm aware a monad is an abstraction and as such it doesn't *do* anything. My point was along the lines that you don't need to know that your working in a field to be able to learn that 3/2 = 1.5 .

Re: [Haskell-cafe] Explaining monads

Hello, There is clearly a problem with the Haskell/monad tutorials out there... > The tutorials seriously need to step back and start with > something like, "To enforce order of evaluation we evaluate > closures* returning a defined type. The first closure will feed > its result to the second

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Lanny Ripple <[EMAIL PROTECTED]> wrote: > Having just gone through all the tutorials and things (again but > this time I think it stuck) the Haskell community is on the wrong > track as far as teaching Monads to new programmers. > > If I were teaching addition and multiplication to chi

Re: [Haskell-cafe] Explaining monads

Having just gone through all the tutorials and things (again but this time I think it stuck) the Haskell community is on the wrong track as far as teaching Monads to new programmers. If I were teaching addition and multiplication to children I wouldn't start with, "We'll begin by defining an a

Re: [Haskell-cafe] Explaining monads

On 14/08/07, Ronald Guida <[EMAIL PROTECTED]> wrote: > My present goal is to understand monads well enough to be able to > explain them to others. I wonder if it's possible to create a > tutorial that explains monads well enough so that they just "make > sense" or "click" for people. It seems ev

Re: [Haskell-cafe] Explaining monads

Ronald Guida wrote: > > Here is the brief explanation I came up with: > > Arrows and monads are abstract data types used to construct Domain > > Specific Embedded Languages (DSELs) within Haskel. A simple arrow > > provides a closed DSEL. A monad is a special type of arrow that > > creates

Re: [Haskell-cafe] Explaining monads

Ronald Guida wrote: > Given the question "What is a Monad", I would have to say "A Monad is > a device for sequencing side-effects." peterv <[EMAIL PROTECTED]> wrote: > "Side-effects" is a piece of linguistic cruft played fast-and-loose > by too many people in this game. "Sequencing" suffers the

Re: [Haskell-cafe] Explaining monads

uires some explanation of how a Monad can allow for side effects (at least the IO Monad). - Greg - Original Message From: peterv <[EMAIL PROTECTED]> To: Kim-Ee Yeoh <[EMAIL PROTECTED]>; haskell-cafe@haskell.org Sent: Monday, August 13, 2007 10:31:48 AM Subject: RE: [Haskell-c

RE: [Haskell-cafe] Explaining monads

On Mon, 2007-08-13 at 19:31 +0200, peterv wrote: > When I read "side-effects", I understand it as "unwanted effects", like > "aliasing", and "effects depending on the order of execution". I'm not sure > if my understanding here is correct. I hope Haskell does not allow > "side-effects" but only "ef

RE: [Haskell-cafe] Explaining monads

alue you get when evaluating a data constructor? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim-Ee Yeoh Sent: Monday, August 13, 2007 15:30 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Explaining monads Ronald Guida wrote: > >

Re: [Haskell-cafe] Explaining monads

Ronald Guida wrote: > > Given the question "What is a Monad", I would have to say "A Monad is > a device for sequencing side-effects." > There are side-effects and there are side-effects. If the only monad you use is Maybe, the only side-effect you get is a slight warming of the CPU. Dave Men

Re: [Haskell-cafe] Explaining monads

On 11/08/07, Ronald Guida <[EMAIL PROTECTED]> wrote: > > > Here's my interpretation of the table: > > -- > Structure | Subject | Action| Verb | Result > +--+++-- >

Re: [Haskell-cafe] Explaining monads

David Menendez wrote: > > This is probably because no one has found a compelling use case for > comonadic-style programming in Haskell. There have been some > interesting papers, such as "Comonadic functional attribute > evaluation" by Uustalu and Vene, but nothing as compelling as Wadler's > "M

Re: [Haskell-cafe] Explaining monads

Tillmann Rendel wrote: > Ronald Guida wrote: >> Here's a toy language, described by a regular expression: >> 0(10)*110 >> >> I want to read characters, one at a time, and eventually decide to >> "Accept" or "Reject" a string. >> >> Let me try to understand my options. >> >> * With a simple Arrow,

Re: [Haskell-cafe] Explaining monads

Ronald Guida wrote: Here's a toy language, described by a regular expression: 0(10)*110 I want to read characters, one at a time, and eventually decide to "Accept" or "Reject" a string. Let me try to understand my options. * With a simple Arrow, I can create a fixed sequence of "read" opera

Re: [Haskell-cafe] Explaining monads

Stefan O'Rear wrote: > On Sat, Aug 11, 2007 at 03:00:04PM -0400, Ronald Guida wrote: >> The question remains: "What is special about Monad or ArrowApply, >> compared to Arrow?" or "What is more general about Arrow, compared >> to Monad or ArrowApply?" > > If all you have is an Arrow, then you must

Re: [Haskell-cafe] Explaining monads

On Sat, Aug 11, 2007 at 03:00:04PM -0400, Ronald Guida wrote: > The question remains: "What is special about Monad or ArrowApply, > compared to Arrow?" or "What is more general about Arrow, compared to > Monad or ArrowApply?" If all you have is an Arrow, then you must make up your mind what you're

Re: [Haskell-cafe] Explaining monads

David Menendez wrote: > Be sure to read sigpfe's "You could have invented monads!" and the > Wadler paper. > > > > > Most tutorials try to explain

Re: [Haskell-cafe] Explaining monads

Ronald Guida wrote: > > Here's my interpretation of the table: > > -- > Structure | Subject | Action| Verb | Result > +--+++-- > function| a | a-

Re: [Haskell-cafe] Explaining monads

ronguida: > > > Monads are undoubtedly more pervasive, and that could be because there > > aren't as many arrow and comonad tutorials, atomic ones or otherwise. > > Moreover, Comonad isn't even in the standard libraries (Hoogle returns > no results for it). > > When I searched for tutorials on m

Re: [Haskell-cafe] Explaining monads

On 8/10/07, Ronald Guida <[EMAIL PROTECTED]> wrote: > > Kim-Ee Yeoh wrote: > > Monads are undoubtedly more pervasive, and that could be because there > > aren't as many arrow and comonad tutorials, atomic ones or otherwise. > > Moreover, Comonad isn't even in the standard libraries (Hoogle return

Re: [Haskell-cafe] Explaining monads

Brian Brunswick wrote: > g f ??? g ??? f > > application a a->b flip ($) b > monad bind m a a->m b>>= m b > comonad cobind w a w a->b=>> w b > arrowarr a b arr b c >>>

Re: [Haskell-cafe] Explaining monads

Brian Brunswick-5 wrote: > > g f ??? g ??? f > > application a a->b flip ($) b > monad bind m a a->m b>>= m b > comonad cobind w a w a->b=>> w b > arrowarr a b arr b c >

[Haskell-cafe] Explaining monads

(Better view the below in a fixed-width font!) With all the recent monad discussions, I embarked on trying to clarify my own thoughts about them, and started to think about things in terms of just /where/ extra structure is 'understood'. I think I can explain why 'a->IO b' is better than 'IO a->b