From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 8EC6BBB81 for ; Mon, 13 Dec 2004 10:21:36 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBD9Lain005708 for ; Mon, 13 Dec 2004 10:21:36 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA22693 for ; Mon, 13 Dec 2004 10:21:35 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBD9LX6R031408 for ; Mon, 13 Dec 2004 10:21:34 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id iBD9LVSD006245; Mon, 13 Dec 2004 18:21:32 +0900 (JST) Date: Mon, 13 Dec 2004 18:21:17 +0900 (JST) Message-Id: <20041213.182117.79057361.garrigue@math.nagoya-u.ac.jp> To: Thomas.Fischbacher@Physik.Uni-Muenchen.DE Cc: caml-list@inria.fr Subject: Re: [Caml-list] environment idiom From: Jacques Garrigue In-Reply-To: References: <877e9a170412121844b633bb8@mail.gmail.com> <877e9a1704121218456af9df9@mail.gmail.com> X-Mailer: Mew version 4.0.64 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BD5F20.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41BD5F1D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 abstraction:01 algebra:01 monadic:01 closures:01 syntax:01 avoiding:01 idiom:01 syntactic:01 functions:01 imperative:01 imperative:01 jacques:01 jacques:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: From: Thomas Fischbacher > On Sun, 12 Dec 2004, Michael Walter wrote: > > Again I believe we are talking about different kinds of "purity". > > Thomas is obviously right in that the StateTransformer monad (modulo > > unsafe conversions) is pure, you are obviously right in the > > (different) point that _running_ an IO fragment has side effects. > > The key issue is: by not doing I/O, but talking about plans how to do I/O, > you go to a higher level of abstraction that allows you to do magic with > such plans which you just plainly miss if you only know the imperative > ways. It's just like everyone knows how to add (i.e. arithmetics), but > once you learned to talk about properties of addition (i.e. algebra), you > have a much richer point of view that allows you to do quite miraculous > things. > > Of course, it's possible to just forget about all that and fall back to > transliterating imperative code to IO monad code, but it is just as well > possible to find the sum of all the numbers from 1 to 1000 using the > following piece of Maple code: You make me curious. Most of the code I've seen using the IO monad (or the state transformer monad) was just transliterating imperative to monadic code. Of course using closures, but not that much, and you can certainly do that in an impure functional language also. So what is so incredible about the IO monad? By the way, if you want an example of non referentially code, this looks easy: do x <- readInt y <- readInt return (x-y) (The syntax and functions may be wrong but you get the idea.) Of course according to your definition this contains nothing that is not referentially transparent once you've taken the syntactic sugar. But looking at the code, it looks like readInt is executed twice returning different results, i.e. this function does not always return 0. So I suppose this is just an instance of what you see is _not_ what you get, but wasn't referencial transparency about avoiding that? Jacques Garrigue