Disappointment

Disappointment

[Paolo Donadeo]

I'm disappointed with myself and my incredibly low IQ. Late this
evening I decided -- and this is the third time -- to be enlightened
by the concept of monad.

I like functional programming, but monads [1] must be too little to be
grabbed by my mind. This time the interest in monads was aroused by
the interesting article of David Teller, Arnaud Spiwack and Till
Varoquaux [2] about the error monad, but for using the library they
wrote I need at least some knowledge about monads and the do-notation.

I tried with some tutorials found around, but I still cannot catch the
point: what the hell is a monad?

I ask you all: can anyone make me a practical example, something
involving strings, files, the network, an image or sound processing
algorithm, something vaguely real? Not abstract mathematical
structures, beautiful algebraic properties and general statements,
please: the net is full of such tutorials, especially Haskell fan
sites ;-)

Thanks in advance for your patience.


[1] http://en.wikipedia.org/wiki/Monad_(symbol)
[2] http://www.univ-orleans.fr/lifo/Members/David.Teller/publications/ml2008.pdf


-- 
Ing. Paolo Donadeo
Studio Associato 4Sigma
Website: http://www.4sigma.it
Personal website: http://www.donadeo.net/blog
~
~
:wq

Re: [Caml-list] Disappointment

[Till Crueger]

On Mon, 21 Jul 2008 23:28:36 +0200, Paolo Donadeo <p.donadeo@gmail.com>
wrote:
> I like functional programming, but monads [1] must be too little to be
> grabbed by my mind. This time the interest in monads was aroused by
> the interesting article of David Teller, Arnaud Spiwack and Till
> Varoquaux [2] about the error monad, but for using the library they
> wrote I need at least some knowledge about monads and the do-notation.

it might take a while, but it's worth the effort... It took me some time
to get the concept as well. Don't worry it doesn't have to do with your IQ.

> I ask you all: can anyone make me a practical example, something
> involving strings, files, the network, an image or sound processing
> algorithm, something vaguely real? Not abstract mathematical
> structures, beautiful algebraic properties and general statements,
> please: the net is full of such tutorials, especially Haskell fan
> sites ;-)

hmm, very informaly speaking, monads allow you to "wrap up" some other
value, or a set of those... Then of course there are lot's of way's to
wrap something up, so this is really abstract.

One good thing that helped me a lot, was to implement the monads myself in
OCaml, even though i hadn't understood them fully at that time. Try for
example to build your own I/O Monad and it will start to get more clearly
how it works.

> [1] http://en.wikipedia.org/wiki/Monad_(symbol)
I suggest this one instead as a good starting point:
http://en.wikipedia.org/wiki/Monads_in_functional_programming

Good luck,
     Till

p.s. Sorry for everyone who get's this message in error... I am to dumb to  
get the recipient right.. I should go to bed now...



-- 
There is no Keyser Soze.
      -- The Usual Suspects

Re: [Caml-list] Disappointment

[Fabrice Marchant]

On Mon, 21 Jul 2008 23:42:30 +0200
"Till Crueger" <crueger@informatik.uni-bonn.de> wrote:

...
> I suggest this one instead as a good starting point:
> http://en.wikipedia.org/wiki/Monads_in_functional_programming

  Hi !

Among the links appearing at the bottom of this document, this non theoretical-one appears the coolest to understand for me. The "pure function debugging" example allows simple OCaml experimentions :

http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html

Regards,

Fabrice

Re: [Caml-list] Disappointment

[Gabriel Kerneis]

Hi,

> I ask you all: can anyone make me a practical example, something
> involving strings, files, the network, an image or sound processing
> algorithm, something vaguely real? Not abstract mathematical
> structures, beautiful algebraic properties and general statements,
> please: the net is full of such tutorials, especially Haskell fan
> sites ;-)

Xavier Leroy's lesson on monads [1] will certainly be too abstract for
you, but the accompanying Caml code [2] might help you to grasp the
concept. You will find there a lot of example of useful monads. You should
have read some tutorial before, though, not to get lost.

Another very concrete example is Lwt [3], a cooperative thread library
written in monadic style. Don't hesitate to follow the link, it's a
documentation targeted at programmers, without categorical issues and so
on. You will need to read a more general tutorial on monads then, to get
the general idea, but it could be a good starting point to "bind" and
"return" operators.

[1] http://gallium.inria.fr/~xleroy/mpri/progfunc/monads.2up.pdf
[2] http://gallium.inria.fr/~xleroy/mpri/progfunc/monads.ml
[3] http://ocsigen.org/lwt

Regards,
-- 
Gabriel Kerneis

Re: [Caml-list] Disappointment

[Dr. Thomas Fischbacher]

Paolo,

> I'm disappointed with myself and my incredibly low IQ. Late this
> evening I decided -- and this is the third time -- to be enlightened
> by the concept of monad.
 >
> I like functional programming, but monads [1] must be too little to be
> grabbed by my mind. This time the interest in monads was aroused by
> the interesting article of David Teller, Arnaud Spiwack and Till
> Varoquaux [2] about the error monad, but for using the library they
> wrote I need at least some knowledge about monads and the do-notation.

Concerning the I/O monad, maybe a useful approach to think about
a member of a monadic type is to regard it as a "plan to do something".

A plan is - essentially - a data structure, i.e. a mathematical value.
There are well defined operations on plans, but there are only very
few of them. Basically, when you have a plan A do do something and a
plan B to do something, you can use those to make a plan to first do A
and then do B. Also, if you have a plan A to produce X, and, for some X,
you can find a plan B that utilizes X, you can assemble a combined plan
that says: "Use plan A to get X and then do that plan B which
corresponds to this X". After all, as plans have a chronological aspect
to them, essentially all you eventually really can do in terms of
operations on plans is to do one after the other.

So, speaking e.g. about Haskell's monadic I/O, you don't really have a
concept of "printing something", but you do have a concept of
"operations on plans that contain printing instructions". Now, in
a lazy language, such a plan can be constructed lazily, conceptually
infinietly wide and deep, and hence capture all computations. And then,
there is a special "magic wand", which says: "If you give me a plan,
I'll execute it for you". That's it.

> I tried with some tutorials found around, but I still cannot catch the
> point: what the hell is a monad?
> 
> I ask you all: can anyone make me a practical example, something
> involving strings, files, the network, an image or sound processing
> algorithm, something vaguely real? Not abstract mathematical
> structures, beautiful algebraic properties and general statements,
> please: the net is full of such tutorials, especially Haskell fan
> sites ;-)

Computer scientists like to obfuscate dead simple ideas with complicated
looking mathematics to deter commonsense-oriented people from making
embarassing observations, such as that computer science was
unable to see something that actually is pretty much obvious -
for ages... ;-)

-- 
best regards,
Thomas Fischbacher
t.fischbacher@soton.ac.uk

Re: [Caml-list] Disappointment

[Nicolas Pouillard]

[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

Excerpts from Paolo Donadeo's message of Mon Jul 21 23:28:36 +0200 2008:
> I'm disappointed with myself and my incredibly low IQ. Late this
> evening I decided -- and this is the third time -- to be enlightened
> by the concept of monad.
> 
> I like functional programming, but monads [1] must be too little to be
> grabbed by my mind. This time the interest in monads was aroused by
> the interesting article of David Teller, Arnaud Spiwack and Till
> Varoquaux [2] about the error monad, but for using the library they
> wrote I need at least some knowledge about monads and the do-notation.
> 
> I tried with some tutorials found around, but I still cannot catch the
> point: what the hell is a monad?

Two key points that helped me:

* Monads help to separate some plumbing from your code.

* Monads provide a way to abstract code over some "let" construct.

I will note that specific "let" construct "let!", it's somewhat
like the do-notation but more atomic.

Monads also come with "return", but that's not the essence of them.

Think about that example:

  val div : int -> int -> int option
  val square : int -> option

  let f x y =
    match div x y with
    | None -> None (* here 'y' was equal to 0 *)
    | Some z ->
        match square z with
        | None -> None
        | Some x2 -> Some x2

In the previous example the plumbing is error handling (where errors are
represented by None), and the "let!" construct is:

  let! x = e1 in e2   ===>   match e1 with None -> None | Some x -> e2

And "return" is "Some".

Another similar example:

  type ('a,'b) either = Left of 'a | Right of 'b

  val div : int -> int -> (string, int) either
  val square : int -> (string, int) either

  let f x y =
    match div x y with
    | Left error_msg -> Left error_msg
    | Right z ->
        match square z with
        | Left error_msg -> Left error_msg
        | Right x2 -> Right x2

Here the plumbing is still there for "error handling", but is somewhat
different. The "let!" construct is:

  let! x = e1 in e2   ===>   match e1 with Left m -> Left m | Right x -> e2

And "return" is "Right".

Finally one could have used the "let!" construct
abstractly (and also "return").

  let f x y =
    let! z = div x y in
    let! x2 = square z in
    return x2

One can obtain the two previous versions by choosing
which "let!"/"return" we want, namely choosing the monad.

Hope that helps,

-- 
Nicolas Pouillard aka Ertai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [Caml-list] Disappointment

[Dario Teixeira]

Hi,

Some months ago someone posted a comment on the Programming
Reddit that brilliantly summarises monads.  It's the best
intro I've read so far:

http://www.reddit.com/r/programming/info/64th1/comments/c02u9mb

Cheers,
Dario



      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Re: [Caml-list] Disappointment

[Axel Poigné]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

> Computer scientists like to obfuscate dead simple ideas with  
> complicated
> looking mathematics to deter commonsense-oriented people from making
> embarassing observations, such as that computer science was
> unable to see something that actually is pretty much obvious -
> for ages... ;-)


Maybe computer scientists obfuscate. The mathematical concept of  
monads however is dead simple (at least if interpreted in a world of  
sets):

Let X be a set of values and let TX denote a set of "simple terms"  
over these values. A "simple term" may be thought of as either "an  
operator applied to a tuple of values" or "a value", e.g. "values" are  
1,2,3,... and "simple terms" are  3,  +(3,5), ...

Additionally to the "operator" T on sets there are two functions:

	-  \eta: X -> TX that turns a value into a "simple term", e.g.  
\eta(3) = 3
	-  \mu: TX -> X that computes the value of a "simple term", hence  
defines the semantics, e.g. \mu(+(3,5)) = 8.

(T, \eta, and \mu) form a monad if

	- a term that is a value is evaluated to the respective value (which  
is an axiom missing in Haskell if I understood a previous message  
correctly)
	- if we build "complex terms", i.e. iterate the operator T, it does  
not matter in which order one evaluates.

I agree that it gets slightly more involved if one specifies the  
second axiom formally.

Don't know whether this helps to understand monads in programming  
since so far I did not care very much about them. However that's were  
Eugenio Moggi took the idea from when introducing monads to semantics.

Axel



[-- Attachment #2: Type: text/html, Size: 5166 bytes --]

Re: [Caml-list] Disappointment

[Andrej Bauer]

Axel Poigné wrote:
> Maybe computer scientists obfuscate. The mathematical concept of monads
> however is dead simple (at least if interpreted in a world of sets):
> 
> Let X be a set of values and let TX denote a set of "simple terms" over
> these values. A "simple term" may be thought of as either "an operator
> applied to a tuple of values" or "a value", e.g. "values" are 1,2,3,...
> and "simple terms" are  3,  +(3,5), ...
> 
> Additionally to the "operator" T on sets there are two functions:
> 
> -  \eta: X -> TX that turns a value into a "simple term", e.g. \eta(3) = 3
> -  \mu: TX -> X that computes the value of a "simple term", hence
> defines the semantics, e.g. \mu(+(3,5)) = 8.
> 
> (T, \eta, and \mu) form a monad if

This is incorrect. You are describing some sort of a mutant between a
monad and an algebra for a functor T.

A monad T has a different \mu, namely a family of maps (one for each set X)

 \mu_X : T (T X) -> T X

One such \mu takes a "simple term of simple terms over X" and flattens
it to a "simple term over X".

Andrej

Re: [Caml-list] Disappointment

[Axel Poigné]

Of course you are right. Humble apologies. Long time since I worked on  
categories.

Axel

Re: [Caml-list] Disappointment

[Warren Harris]

Here's my layman's perspective...

I think the most important thing to understand about monads is that  
they allow a bit of data (state) to follow the control flow of your  
program... around loops (via tail-recursion), through assignments (via  
the 'bind' operator) and out of one routine and into another (via  
'return'). As the state goes along for this ride, it can be accessed  
and updated (replaced with a new state). This is how Haskell  
implements imperative constructs -- it propagates them in this bit of  
state that flows through the program.

To understand this, I would start with the state-transition monad.  
There it's easy to see how 'bind' propagates state, and how 'return'  
packages state into the result.

Things get interesting with monads when this state contains  
continuations -- functions that have been captured along the way and  
stored in the state can be later invoked to return control to previous  
points in your program. A monadic version of call/cc (e.g. from  
scheme) can be implemented this way. This is essentially what enables  
lightweight thread packages like Lwt to suspend and resume control.

Perhaps one non-obvious thing about monads is how they hide this state  
from the program that uses it. Operations that are "in the monad" can  
see an manipulate the state. It appears as additional parameters to  
the operation, or (more accurately) as parameters to a function being  
returned from the monadic operation. Operations that simply use the  
monad are really composing these functional pieces together (along  
with their own bits of non-monadic code) to build up bigger monadic  
operations.

Running a monadic program really has 2 distinct phases: First  
composing all the pieces together (which is why it's critical that non- 
monadic operations be lazy or hidden inside functions that defer them  
until the second phase). (Monadic interpreters use the AST to drive  
this composition process.) Second is the application to the state  
which puts the whole machine in motion, producing the final result or  
effect of the program.

I hope this explanation helps. I've found monads to be an amazing  
powerful abstraction, although the explanations of them are often  
academic and difficult to get one's head around. Understanding them  
can open many new possibilities however,

Warren


On Jul 21, 2008, at 2:28 PM, Paolo Donadeo - p.donadeo@gmail.com wrote:

> I'm disappointed with myself and my incredibly low IQ. Late this
> evening I decided -- and this is the third time -- to be enlightened
> by the concept of monad.
>
> I like functional programming, but monads [1] must be too little to be
> grabbed by my mind. This time the interest in monads was aroused by
> the interesting article of David Teller, Arnaud Spiwack and Till
> Varoquaux [2] about the error monad, but for using the library they
> wrote I need at least some knowledge about monads and the do-notation.
>
> I tried with some tutorials found around, but I still cannot catch the
> point: what the hell is a monad?
>
> I ask you all: can anyone make me a practical example, something
> involving strings, files, the network, an image or sound processing
> algorithm, something vaguely real? Not abstract mathematical
> structures, beautiful algebraic properties and general statements,
> please: the net is full of such tutorials, especially Haskell fan
> sites ;-)
>
> Thanks in advance for your patience.
>
>
> [1] http://en.wikipedia.org/wiki/Monad_(symbol)
> [2] http://www.univ-orleans.fr/lifo/Members/David.Teller/publications/ml2008.pdf
>
>
> -- 
> Ing. Paolo Donadeo
> Studio Associato 4Sigma
> Website: http://www.4sigma.it
> Personal website: http://www.donadeo.net/blog
> ~
> ~
> :wq
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Disappointment

[Christophe TROESTLER]

Hi, 

You may want to take a look to 
http://cufp.galois.com/2007/slides/ChrisWaterson.ppt
for an actual use of monads in a concrete product.

Cheers,
C.

Re: [Caml-list] Disappointment

[Paolo Donadeo]

Thanks to you all for explanations and links. I have material for days.


-- 
Paolo
~
~
:wq