From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,HTML_MESSAGE,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 9F5EEBBAF for ; Tue, 22 Jul 2008 15:27:48 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoAAMd8hUiZYAE4mWdsb2JhbACCco9VAQEBAQEIBQYJEQWdLA X-IronPort-AV: E=Sophos;i="4.31,231,1215381600"; d="scan'208,217";a="15380619" Received: from iron02.fraunhofer.de ([153.96.1.56]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2008 15:27:48 +0200 Received: from kso.iais.fraunhofer.de ([193.175.162.66]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2008 15:27:42 +0200 Received: from ksi.iais.fraunhofer.de (ksi.iais.fraunhofer.de [129.26.64.2]) by kso.iais.fraunhofer.de (8.13.5+/8.13.5) with ESMTP id m6MDRfD9004530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jul 2008 15:27:42 +0200 (CEST) X-Received: -iais.fraunhofer.de-routing from ksi.iais.fraunhofer.de (localhost [127.0.0.1]) by ksi.iais.fraunhofer.de (8.13.5+/8.13.5) with ESMTP id m6MDRauj021743 for ; Tue, 22 Jul 2008 15:27:36 +0200 (CEST) Received: from mbpaxel.ais.fraunhofer.de (mbpaxel.ais.fraunhofer.de [129.26.151.93]) by ksi.iais.fraunhofer.de (8.13.5+/8.13.5) with ESMTP id m6MDRaKh021740 for ; Tue, 22 Jul 2008 15:27:36 +0200 (CEST) Message-Id: <5D9CA6BE-731F-45A7-A1CC-AF1DC0556314@iais.fraunhofer.de> From: =?ISO-8859-1?Q?Axel_Poign=E9?= To: caml-list caml-list In-Reply-To: <4885BCC5.6080802@soton.ac.uk> Content-Type: multipart/alternative; boundary=Apple-Mail-2-55371162 Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [Caml-list] Disappointment Date: Tue, 22 Jul 2008 15:27:35 +0200 References: <4b5157c30807211428r19ef9865n6a65e81ac2f5fe31@mail.gmail.com> <4885BCC5.6080802@soton.ac.uk> X-Mailer: Apple Mail (2.926) X-Spam: no; 0.00; fraunhofer:01 monads:01 computes:01 semantics:01 haskell:01 specifies:01 monads:01 moggi:01 semantics:01 computes:01 haskell:01 specifies:01 moggi:01 808000:98 defines:01 --Apple-Mail-2-55371162 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > 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 --Apple-Mail-2-55371162 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
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) =3D 3
- =  \mu: TX -> X that computes the value of a "simple term", hence = defines the semantics, e.g. \mu(+(3,5)) =3D = 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


= --Apple-Mail-2-55371162--