Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: WWAAA... I hate monads (Daniel Carrera)
2. Re: WWAAA... I hate monads (Jason Dusek)
3. Re: WWAAA... I hate monads (Thomas Davie)
4. Re: WWAAA... I hate monads (Daniel Carrera)
5. Re: WWAAA... I hate monads (Sergey V. Mikhanov)
6. Re: WWAAA... I hate monads (Jason Dusek)
7. Re: WWAAA... I hate monads (Brent Yorgey)
8. Re: WWAAA... I hate monads (Daniel Carrera)
9. computation vs function (Daniel Carrera)
10. Re: computation vs function (Brent Yorgey)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Apr 2009 13:01:46 +0200
From: Daniel Carrera <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Daniel Carrera wrote:
> Colin Paul Adams wrote:
>> This is excellent:
>>
>> http://ertes.de/articles/monads.html
>
> Thanks! I'll start reading that page immediately.
I noticed that this tutorial points to the following blog:
http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
Wow! The author of this blog has nailed it. Trust me, I know, I was a
math teacher for years (a *good* teacher, based on student reviews). The
author of this blog is exactly right about why most tutorials about
abstract concepts are no help (and why so many math teachers are bad).
Now I'll go on to read the tutorial, encouraged that the author probably
knows how to teach.
Cheers,
Daniel.
------------------------------
Message: 2
Date: Wed, 22 Apr 2009 04:26:12 -0700
From: Jason Dusek <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: Daniel Carrera <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
2009/04/22 Daniel Carrera <[email protected]>:
> I hate monads.
Yikes! How do you feel about functors?
> 1) I know what a type is, but not a "type constructor". I
> don't normally think of an Int or even a complex type as being
> "constructed" except in the sense of OOP which I know is not
> what the author means.
Well, an object constructor takes values and makes a value. A
type constructor takes types and makes a type. You've probably
seen a few type constructors in your life, for example,
`std::vector`, which makes vectors of type `std::vector<t>`.
Likewise, `std::map` is a two argument type constructor.
> 2) Just *read* the paragraph... "a type constructor, a
> function that builds value of that type, and a function that
> combines values of that type with computations that produce
> values of that type to produce a computation of values of that
> type" Â Ugh....
I don't think you should take your first impression too
seriously here. The notion of combining computations is really
crucial to working with monads; you'll find it's pretty hard
to get used to at first, no matter how it's presented.
--
Jason Dusek
------------------------------
Message: 3
Date: Wed, 22 Apr 2009 13:42:19 +0200
From: Thomas Davie <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: Colin Paul Adams <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
delsp=yes
On 22 Apr 2009, at 12:26, Colin Paul Adams wrote:
>>>>>> "Daniel" == Daniel Carrera <[email protected]> writes:
>
> Daniel> Can anyone recommend a simple and clear explanation of
> Daniel> monads? You can assume that I know basic math and basic
> Daniel> Haskell syntax. So, for example, "a -> b" is much more
> Daniel> clear than "a function that takes input of one type and
> Daniel> has an output of a different type".
>
> This is excellent:
>
> http://ertes.de/articles/monads.html
Hopefully this will help too - monads are made rather too much of,
just build up slowly to them rather than diving into them first
they're not the be all and end all of classes.
http://noordering.wordpress.com/2009/03/31/how-you-shouldnt-use-monad/
Bob
------------------------------
Message: 4
Date: Wed, 22 Apr 2009 13:52:14 +0200
From: Daniel Carrera <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andrew Wagner wrote:
> Here's a clearer description:
> class Monad m where
> return :: a -> m a
> (>>=) :: m a -> (a -> m b) -> m b
>
> Instances of Monad must satisfy the following laws:
> return a >>= k == k a
> m >>= return == m
> m >>= (k >>= h) == (m >>= k) >>= h
>
> Much more clear and concise, don't you think?
Actually, that /is/ clearer for me. Though I still think I'll need the
tutorial Colin gave me to gain better intuition and understand the
motivations behind monads. That said, I do have questions:
1) Am I right in thinking that any type with two elements ("m a") is
always a Monad? (IO String, Maybe Int, etc).
2) When I say "m a >>= f" the >>= just pulls the "a" out of "m a" and
passes it to "f". Right?
3) The last two properties are not comparing values but functions.
Right? For example, reading the second-last property:
(m >>= return) :: a -> m a
Where (m >>= return) is defined by (\x -> m x >>= return). Right? And
this is why you can write the last property:
(k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is what allows
us to make (k >>= h) the second argument of ">>=" as in the last property:
m >>= (k >>= h) == (m >>= k) >>= h
Am I right?
Thanks,
Daniel.
------------------------------
Message: 5
Date: Wed, 22 Apr 2009 14:01:28 +0200
From: "Sergey V. Mikhanov" <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: Daniel Carrera <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> 1) Am I right in thinking that any type with two elements ("m a") is always
> a Monad? (IO String, Maybe Int, etc).
>
> 2) When I say "m a >>= f" the >>= just pulls the "a" out of "m a" and passes
> it to "f". Right?
>
> 3) The last two properties are not comparing values but functions. Right?
> For example, reading the second-last property:
>
> (m >>= return) :: a -> m a
>
> Where (m >>= return) is defined by (\x -> m x >>= return). Right? And this
> is why you can write the last property:
>
> (k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is what allows us to
> make (k >>= h) the second argument of ">>=" as in the last property:
>
> m >>= (k >>= h) == (m >>= k) >>= h
>
> Am I right?
I am also a beginner, so you should take my words with the grain of
salt. Strange enough, the monad description that helped me most is the
Wikipedia article:
http://en.wikipedia.org/wiki/Monad_(functional_programming)
This basically answers some of your questions by defining monad as
triple (type constructor, bind function and return function), with
certain properties.
S.
------------------------------
Message: 6
Date: Wed, 22 Apr 2009 05:31:33 -0700
From: Jason Dusek <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: Daniel Carrera <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
2009/04/22 Daniel Carrera <[email protected]>:
> 1) Am I right in thinking that any type with two elements
> ("m a") is always a Monad? (IO String, Maybe Int, etc).
Well, no. Many such types are monads but not all of them.
Monads have the monadic operations `return` and `>>=`.
> 2) When I say "m a >>= f" the >>= just pulls the "a" out of "m
> a" and passes it to "f". Right?
Yes. The `>>=` operators defines our evaluation strategy; it
allows us to combine computations. Be carefult of confusing
`m` (a type constructor) with the value constructors for a
particular monad.
> 3) The last two properties are not comparing values but
> functions. Right? For example, reading the second-last
> property:
>
> (m >>= return) :: a -> m a
Not quite -- `someMonadicValue >>= return` is of type `m a`.
> Where (m >>= return) is defined by (\x -> m x >>= return).
> Right? And this is why you can write the last property:
>
> (k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is
> what allows us to make (k >>= h) the second argument of ">>="
> as in the last property:
Actually, the third law is:
(m >>= f) >>= g = m >>= (\x -> f x >>= g)
--
Jason Dusek
------------------------------
Message: 7
Date: Wed, 22 Apr 2009 08:51:55 -0400
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Apr 22, 2009 at 01:01:46PM +0200, Daniel Carrera wrote:
> Daniel Carrera wrote:
>> Colin Paul Adams wrote:
>>> This is excellent:
>>>
>>> http://ertes.de/articles/monads.html
>> Thanks! I'll start reading that page immediately.
>
> I noticed that this tutorial points to the following blog:
>
> http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
>
> Wow! The author of this blog has nailed it. Trust me, I know, I was a math
> teacher for years (a *good* teacher, based on student reviews). The author
> of this blog is exactly right about why most tutorials about abstract
> concepts are no help (and why so many math teachers are bad).
Thanks! =) You may also be interested in taking a look at the
Typeclassopedia, in issue 13 of the Monad.Reader.
http://haskell.org/haskellwiki/The_Monad.Reader
-Brent
------------------------------
Message: 8
Date: Wed, 22 Apr 2009 15:17:03 +0200
From: Daniel Carrera <[email protected]>
Subject: Re: [Haskell-beginners] WWAAA... I hate monads
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Jason Dusek wrote:
> Actually, the third law is:
>
> (m >>= f) >>= g == m >>= (\x -> f x >>= g)
Yeah. I just saw that in the tutorial. And it actually makes more sense
that way (esp after reading some of the tutorial):
1) A "computation" is something that may have a result.
2) In "m >>= f", m is a computation and f is a function that takes a
value and returns a computation. >>= takes the output of m and makes it
the input of f.
3) Therefore, the value of "m >>= f" is a computation.
4) Because "m >>= f" is a computation, it can be the left parameter of
another >>=, as in "(m >>= f) >>= g".
5) If "x" is a value then "f x" is a computation. Thus, "f x" can be the
left parameter of >>=, as in "f x >>= g", and the result of that is a
computation.
6) Therefore, (\x -> f x >>= g) is a function that takes a value ("x")
and returns a computation, so it can be the right parameter of >>=.
I think I get it (at least this part).
Cheers,
Daniel.
------------------------------
Message: 9
Date: Wed, 22 Apr 2009 22:38:14 +0200
From: Daniel Carrera <[email protected]>
Subject: [Haskell-beginners] computation vs function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
I have finished the tutorial at http://ertes.de/articles/monads.html and
my understanding of monads has increased greatly. I still need to cement
some concepts in my mind. What exactly is the difference between a
computation and a function? Monads revolve around computations, so I'd
like to understand computations better.
Thanks for the help.
Daniel.
------------------------------
Message: 10
Date: Wed, 22 Apr 2009 16:46:07 -0400
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Apr 22, 2009 at 10:38:14PM +0200, Daniel Carrera wrote:
> Hello,
>
> I have finished the tutorial at http://ertes.de/articles/monads.html and my
> understanding of monads has increased greatly. I still need to cement some
> concepts in my mind. What exactly is the difference between a computation
> and a function? Monads revolve around computations, so I'd like to
> understand computations better.
"Computation" does not really have any technical meaning, it's just
supposed to be an intuition. But the term "computation" is often used
to refer to things of type (m a) where m is a Monad. You can clearly
see from the types that something of type (m a) is different than
something of type (a -> b). The former takes no inputs and somehow
produces value(s) of type a; the latter takes something of type a as
input and produces something of type b as output.
However, you could also legitimately thing of things of type (a -> b)
as "computations"; more interestingly, you can think of things of type
(a -> m b) as "parameterized computations" which can be composed in
nice ways.
Don't rely too heavily on the "computation" idea; monads certainly
don't "revolve around computations", it's only one particular way of
giving intuition for monads which does.
-Brent
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 10, Issue 21
*****************************************
