A propos de monad

A propos de monad

[Stéphane Baubillier]

Ayant déjà poser la question sur les news comp.lang.functionnal,
Quelqu'un aurait-il une traduction de 'monad' et des info sur les causes (et
raisons) de son existance.

Merci.

Stéphane Baubillier
baubillier@hotmail.com

Re: A propos de monad

[David Gross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 499 bytes --]




> Ayant déjà poser la question sur les news comp.lang.functionnal,
> Quelqu'un aurait-il une traduction de 'monad' et des info sur les causes (et
> raisons) de son existance.

Je ne suis pas du tout un specialiste, mais je crois que les monades
servent a realiser simplement dans un langage fonctionnel la notion de
changement d'etat d'un programme.



Un petit lien : http://www.dcs.gla.ac.uk/~nww/Monad.html (c'est de
l'haskell)


David Gross
http://www.lri.fr/~dgross

Re: A propos de monad/About monads

[David Mentr'e]

[ English (executive summary ;) ]

Monads are a way to encapsulate side-effects in functionnal
languages. Does anyboody have a more detailed explaination about how
monads really work ? What is the difference between the usual let and
the monad binding ?

[ Français ]
"Stéphane Baubillier" <stephane.baubillier@pactenovation.fr> writes:

> Quelqu'un aurait-il une traduction de 'monad'

? monade ? (c'est au moins dans le dico)

> et des info sur les causes (et raisons) de son existance.

C'est un mécansime pour encapsuler les effets de bord dans un formalisme
fonctionnel. Pour résumer très grossièrement, une fonction ne doit
dépendre que de ses entrées. Donc pour que les effets de bord puissent
être pris en compte, on passe en argument de la fonction un « monde »,
qu'elle rend modifié. Ce monde comprend le résultat de la fonction, plus
tous les effets de bords potentiels (exception, ...). 

Donc les monades sont un type abstrait de donné. De plus, ce type
abstrait doit avoir certaines caractéristiques : un opérateur de liage
(/binding/) et un élément neutre (/unit/) et des lois sur la composition
de ces éléments. Il se trouve que ces lois correspondent aux
caractéristiques des monades en mathématiques, d'où le nom.

Un dernier point, il semble que l'opérateur de liage/binding permet de
séquentialiser les opérations. D'où maintenant ma question : quelle est
la différence entre un binding de monade et un let plus classique ?


Quelques articles de référence sur les monades :

http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html

Philip Wadler semble un des gourous du domaine. Il a notamment
popularisé son usage dans Haskell (cf. haskell.org pour plus d'infos sur
ce langage).

Mon explication est très sommaire. Je n'ai jamais réussi à réellement
bien comprendre quelle était la caractéristique exacte, précise, des
monades. Quelqu'un possède-t-il une explication plus détaillée sur le
comment et le pourquoi (notamment lien et différence entre let classique
et binding de monade)?

Amicalement,
d.
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

Re: A propos de monad/About monads

[David Brown]

David Mentr'e writes:

 > Monads are a way to encapsulate side-effects in functionnal
 > languages. Does anyboody have a more detailed explaination about how
 > monads really work ? What is the difference between the usual let and
 > the monad binding ?

Monads are primarily to encourage a lasy language (such as haskell) to 
evaluate side-effecting operations in a specific order.

In caml,

   let a = foo x y z in
   let b = bar g h i in
   blort a b

foo will be called before bar, and both will be called before blort.
So, if there are side effects in foo, and bar, and blort, we know what 
order these will happen in.

In a lazy language, foo will not be evaluated until blort needs to use 
its first argument.  Things could happen in blort before that.
Consequentially, some mechanism is needed to ensure an order.  Instead 
of "hiding" side-effecting operations wherever convenient, they are
encapsulated into a monad.  Other messages have given good references
to explanations.

Basically, instead of a function performing an operation, it returns a 
function that will perform that operation.  Monads provide a
convenient way to sequence these.  Also, the main program will return
a monad.  It is up to the runtime to then perform this operation
(basically outside of the scope of the language).

Dave Brown

RE: A propos de monad/About monads

[Frank A. Christoph]

> [ English (executive summary ;) ]
>
> Monads are a way to encapsulate side-effects in functionnal
> languages. Does anyboody have a more detailed explaination about how
> monads really work ? What is the difference between the usual let and
> the monad binding ?

Someone already gave a URL for Noel Winstanley's presentation of monads in
Haskell. I wanted to point out that there are several other resources listed
at

http://haskell.org/bookshelf/

under "Using Monads".

Philippe Esperet wrote:
> 	``monad'' est le mot anglais correspondant ·<< monade >>, entit·
> complexe intervenant dans le syst?e philosophique de Leibniz (Monade
> en allemand).

I don't understand French, but I parsed this as saying that monads in the
sense used here have something to do with Leibniz's philosophical theory of
monads, which is false.

A monad, as used in Haskell and the progamming language theory literature,
is a mathematical structure from category theory. One way to think of it is
as a (polymorphic) computation over algebras of a functor.

Leibniz's monads were a semi-mystical attempt at explaining the structure of
matter.

You might think that at least the origins of the words are related, but I
doubt it. Another way to think of the notion of monad is as a
categorification of the algebraic notion of monoid (the functions become
functors, the points become morphisms, etc.), so I assume "monad" came from
"monoid". BTW, another word for "monad" is "triple" (because it is described
by one functor and two natural transformations), and I believe the latter is
in fact more common in pure mathematical circles.

David Brown wrote:
> Monads are primarily to encourage a lasy language (such as haskell) to
> evaluate side-effecting operations in a specific order.

But monads are also used in Opal, which is an eager language, to keep the
base language pure from side-effects.

Also, I often use monads in Haskell which have no side-effects at all. For
example, I might use a non-imperative state transformer to "lay out the
plumbing" for an algorithm, i.e., to avoid passing variables around
explicitly; the error monad, which is a monad over what in Ocaml corresponds
to the option type (functor), is also extremely useful, and has no
side-effects either.

--FAC

RE: A propos de monad/About monads

[Frank A. Christoph]

I wrote:
> Philippe Esperet wrote:
> > 	``monad'' est le mot anglais correspondant ?<< monade >>, entit?
> > complexe intervenant dans le syst?e philosophique de Leibniz (Monade
> > en allemand).
>
> I don't understand French, but I parsed this as saying that monads in the
> sense used here have something to do with Leibniz's philosophical
> theory of monads, which is false.

Toby Moth has informed me (and given a semi-mystical exposition involving
the Holy Trinity :) of another notion of "monad" hailing from non-standard
real analysis, due to the logician Robinson, and in this case it appears
that the term was in fact derived from Leibniz's ideas. These monads of
course have nothing to do with the ones from category theory, which are the
ones relevant for denotational semantics and functional programming.

--FAC

Re: A propos de monad/About monads

[John Prevost]

Frank A. Christoph <christo@nextsolution.co.jp> writes:

> But monads are also used in Opal, which is an eager language, to keep the
> base language pure from side-effects.
> 
> Also, I often use monads in Haskell which have no side-effects at all. For
> example, I might use a non-imperative state transformer to "lay out the
> plumbing" for an algorithm, i.e., to avoid passing variables around
> explicitly; the error monad, which is a monad over what in Ocaml corresponds
> to the option type (functor), is also extremely useful, and has no
> side-effects either.

I spent some time last year working with monadic parsers--this is
another really nice way to use monads (especially if you have monad
comprehensions.)  An example, using something like what I wrote to do
Monad comprehensions in camlp4:

let char c = << x | x <- item; x = c >>
let digit = << x | x <- item; x >= '0' && x <= '9' >>
let rec many p = << x::xs | x <- p; xs <- many p >>
let number = many digit

let bracket l p r = << x | _ <- l; x <- p; _ <- r >>
let rec seq p s = << x :: xs | x <- p; _ <- s; xs <- seq p s >>
              |-| << [x] | x <- p >>

let number_list = bracket (char '[') (seq number (char ',')) (char ']')

And then number_list would parse something like "[1,2,3,4,56]" into
the Caml value [1; 2; 3; 4; 56].

Unfortunately, this kind of thing (along with other higher-order
combinator stuff for, as an example, formatted printing) doesn't work
that well in ML because of the value restriction.  :(

John.

RE: A propos de monad/About monads

[Jan Skibinski]

On Mon, 4 Oct 1999, Frank A. Christoph wrote:

> Toby Moth has informed me (and given a semi-mystical exposition involving
> the Holy Trinity :) of another notion of "monad" hailing from non-standard
> real analysis, due to the logician Robinson, and in this case it appears
> that the term was in fact derived from Leibniz's ideas. These monads of
> course have nothing to do with the ones from category theory, which are the
> ones relevant for denotational semantics and functional programming.
> 
> --FAC
> 

	As a practitioner of monads you may find this Leibnitz's
	statement interesting:

	"Monads have no windows by which anything goes in or out" 

	Did he predict monadic IO here? :-)

	There are few statements in his "Monadologia" that may
	explain the reasons why the name "monad" was borrowed by the
	category theory.

	Generally, what he wrote about monads might seem laughable
	to us now, but I have some respect to his other philosophical
	thoughts, particularly about time and space (isotropic,
	anisotropic, absolute, relative?). Modern physics considers such
	questions relevant.

 	I also vaguely remember some old text (arabic?) which mentions
	monads as well. The concept of monads might have been much older
	than we think.

	Jan

RE: A propos de monad/About monads

[Frank A. Christoph]

> I spent some time last year working with monadic parsers--this is
> another really nice way to use monads (especially if you have monad
> comprehensions.)
> ...[example omitted]...

Ah! Parsers a great example of a useful monad without side-effects; I can't
believe I forgot to mention them. Actually, though, I have been using
Swierstra & Duponcheel's parser combinators (they are much more efficient)
for a while now and these, as is now well-known, cannot be expressed as a
monad.

Interested people can find out about them at:
 http://www.cs.uu.nl/groups/ST/Software/Parse/

> Unfortunately, this kind of thing (along with other higher-order
> combinator stuff for, as an example, formatted printing) doesn't work
> that well in ML because of the value restriction.  :(

Yes. And maybe one reason I didn't mention parsers is that combinator
languages like this do not work as nicely in eager languages like ML as they
do in non-strict ones like Haskell. Aside from the fact that you have to
eta-expand lots of definitions, eager evaluation also forces you to turn
recursive operators like (say) the Kleene star into primitives, whereas in a
lazy regime you can define them at the object level, i.e., in terms of other
combinators. I guess you got around this by using the Lazy module...?

--FAC