subject:"RE\: \[Haskell\-cafe\] Explaining monads"

Re: [Haskell-cafe] Explaining monads

2007-08-16 Thread Kim-Ee Yeoh

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 after I combine all of my
> actions together that I apply the result to my input (via "run").
> 
> Well, that's just like function composition.  In particular, if I have a
> function f, and a function g, I can think of them as recipes, because I
> can combine them via f . g.
> 

First a nitpick:

At the beginning of the thread I had pointed out how co/monadic 
co/bind generalizes function /application/, i.e. flip ($).

Generalized function /composition/ on the other hand has a different 
type. For instance, in the case of monads it's

\begin{code}

(<.>) :: Monad m => (a -> m b) -> (c -> m a) -> (c -> m b)
(<.>) f g c = (g c) >>= f

\end{code}

Function (<.>) is flip (>>>) in the instance of Monad m => Arrow
(Kleisli m). (For a moment there I couldn't find it in the haskell
libs. Would be nice if Hoogle could read instances such as these. I
must not be using Hoogle right, I couldn't even locate (>>=) by
type signature.)

Returning to the main point, like you and Dan P, I also have my
reservations explaining a monadified value as a recipe, although
for arguably different reasons. It's too chef-centric for me, to
continue with the original analogy. I have an allergic reaction to
"run" functions, at least what they connote. I claim that in
genuinely monadic programming, you never think about "run". Code
that's genuinely monadic works for all monads. Code like that is
what you want to write.

Or put another way, you just program like before except lifting
stuff into an arbitrary monad. You then write different monads
to retrofit the various add-on computations you want performed.

I thought this is well-known for over 15 years?

-- 
View this message in context: 
http://www.nabble.com/Explaining-monads-tf4244948.html#a12185261
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] Explaining monads

2007-08-15 Thread Paul Hudak

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 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 after I combine all of my actions 
together that I apply the result to my input (via "run").


Well, that's just like function composition.  In particular, if I have a 
function f, and a function g, I can think of them as recipes, because I 
can combine them via f . g.  It's only after I combine all of my 
functions together that I apply the result to my input.


   -Paul


Sebastian Sylvan wrote:

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 complicated.
  

It certainly is complicated. I think I have a good grasp of monads to
the point where I can tease novel monads (and comonads) out from
algorithms that people previously didn't see as monadic. And yet I
still don't understand what you are saying (except with respect to one
specific monad, IO, where I can interpret 'action' as meaning an I/O
operation).



Monads have a monadic type. They
represent an abstract form of an "action", which can be viewed as an
analogy to real-world cooking recipes.
  

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.



No, (+) is a function, not a "recipe". Again, you're introducing
confusion because you use the same analogy for two *different* things.
Use it for one of the things and you don't have that problem.
I want to use "recipe" to mean "an abstraction for an action". It
could litterally be a text string containing the C code required to do
a particular IO action, for example. (+) isn't an abstraction in the
same sense, it *is* the "action" itself. (+) is the actual value of
the function that will add two numbers together. A monadic value is an
abstract recipe that you can't actually use directly (you can only
combine them, and if you're lucky you can "perform" them once you're
done combining them, e.g. ST, but not IO).


  

As long as you don't
deliberately confuse things by using the same analogy for two
different things I don't see where confusion would set in.
  

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 recipes.



Why would you? I really don't see where you would get that idea? If I
tell you that a function returns "a fruit", would you ask where the
fruit in your factorial program is? Probably not. Why would you go off
and take an analogy for monads and apply it to something completely
different and still think the analogy holds?
A function is *not* a recipe in this analogy, it's just a function
(which you hopefully should've covered by the time you get to monads.
Monadic values, and *only* monadic values (not functions!) are to be
viewed as analogous to real world cooking recipes in this analogy.
Functions shouldn't. If you start mixing things together it will get
confused, so just don't!

I don't think this is very difficult to understand, so if you still
don't get it, I think you're just going to have to read it again
because I can't explain it any better, and in my experience, newbies
tend to understand this analogy within seconds (maybe that's the
problem, you're not a newbie)...
  
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Explaining monads

2007-08-15 Thread Andy Gimblett

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.  This ties in to the open-endedness of Haskell; I
> sometimes think that really understanding all of Haskell is like
> really understanding all of mathematics.  This is frustrating, but
> it's also what makes the language so rewarding.  I guess what I'm
> saying is: get used to it, it's not so bad.

At AngloHaskell, one of Phillipa's slides referred to Haskell as a
"programming language theory gateway drug" - and was clearly of the
opinion that this was A Good Thing.

-- 
Andy Gimblett
Computer Science Department
University of Wales Swansea
http://www.cs.swan.ac.uk/~csandy/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Explaining monads

2007-08-14 Thread Michael Vanier

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 really
understanding all of Haskell is like really understanding all of mathematics. This is frustrating,
but it's also what makes the language so rewarding. I guess what I'm saying is: get used to it,
it's not so bad.

Mike

Derek Elkins wrote:

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
individually in my career. I have referred them to many
tutorials. I have used many examples from tutorials I thought
were useful. I can't recall a single time I've ever turned to a
beginner and said, "And you really should brush up on the
peer-reviewed papers to learn this part."

How about a book? You've never recommended a book? But even so, where
did I say tutorial? The -are- good monad tutorials, they are just
horribly out-weighed by bad ones. Further, having a tutorial as
supplement to person-to-person education is totally different from
trying to learn purely from tutorials. Also, what is wrong with papers
or recommending them? Finally, how often have you been part of a
community where the primary mode of documentation is a research paper...

by the people who clearly know what they are talking about. Luckily,
for monads applied to Haskell we have Wadler, a witty, enjoyable and
clear writer/speaker. All of Wadler's monad "introductions" are
readable by anyone with a basic grasp of Haskell. You certainly don't
need to be even remotely an academic to understand them. I'm willing to
bet that many people who say they don't understand monads and have read
"every tutorial about them" haven't read -any- of Wadler's papers.

I'm confused. Are you praising Wadler or bashing the tutorials
(or both)? *I* was carping about the tutorials (and even
mentioned that Wadler was my breakthrough) so I suspect we are in
violent agreement.

I'm praising Wadler and bashing the good majority of monad tutorials,
but not all of them. Mostly I'm pointing out an unreasonable aversion
to reading papers, as if a paper couldn't possibly be understandable.

50 matches

Mail list logo