From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 7D8EABB81 for ; Sun, 12 Dec 2004 20:09:49 +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 iBCJ9mOT007963 for ; Sun, 12 Dec 2004 20:09:48 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA00239 for ; Sun, 12 Dec 2004 20:09:48 +0100 (MET) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBCJ9kWP007958 for ; Sun, 12 Dec 2004 20:09:47 +0100 Received: by rproxy.gmail.com with SMTP id c16so1318133rne for ; Sun, 12 Dec 2004 11:09:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rdpHB3smFqPh0OTwk7KdGekDj9pnBE/58Qt5E/FjFBIK2yDB3IwKpLmZ3E1aei/vNLj7m02y4Kkh7nPoXeRSMdxon8UTVAwqrwAT3fTGw+Gis/4CoKH5TXZDp7QaBFXy+lE7gdFlQKMuHI0SU54lsci4S07o0fkdx9Arg7kQCBs= Received: by 10.38.74.68 with SMTP id w68mr899780rna; Sun, 12 Dec 2004 11:09:45 -0800 (PST) Received: by 10.38.86.10 with HTTP; Sun, 12 Dec 2004 11:09:45 -0800 (PST) Message-ID: <877e9a170412121109ec02d44@mail.gmail.com> Date: Sun, 12 Dec 2004 14:09:45 -0500 From: Michael Walter Reply-To: Michael Walter To: skaller@users.sourceforge.net Subject: Re: [Caml-list] environment idiom Cc: William Lovas , caml-list In-Reply-To: <1102829608.2768.77.camel@pelican.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com> <41B97FD7.50309@andrej.com> <1102732237.2611.580.camel@pelican.wigram> <41BB04D8.60405@andrej.com> <20041211181313.GA9656@fichte.ai.univie.ac.at> <1102809398.2611.637.camel@pelican.wigram> <20041212023636.GA12724@force.stwing.upenn.edu> <1102829608.2768.77.camel@pelican.wigram> X-Miltered: at nez-perce with ID 41BC977C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BC977A.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 monadic:01 monads:01 idiom:01 functions:01 functions:01 reasoning:01 argument:01 purely:02 functional:02 languages:03 dec:03 indeed:05 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=RCVD_BY_IP autolearn=disabled version=3.0.0 X-Spam-Level: On 12 Dec 2004 16:33:29 +1100, skaller wrote: > Yes, that indeed is my intention. Basically, any non-transparent > non-function code can be made purely functional and transparent > with a simple transformation, yet it doesn't by this transformation > get any easier to reason about the code. Well, actually monadic I/O makes is easier to reason about code than languages which allow for non-transparent side effects in functions. I think you were making a really good argument pro monads yourself -- in your C interpreter monad you can easily see what's making use of the C interpreter (any function "in"/lifted to the C interpreter monad), and what's not. Same for I/O -- you can assume that only functions "in"/lifted to the IO monad (simply said, every value of type IO a) are able to do I/O. This clearly allows easier reasoning about code. - Michael