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 78EE2BB81 for ; Mon, 13 Dec 2004 13:48:41 +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 iBDCme8Z008230 for ; Mon, 13 Dec 2004 13:48:40 +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 NAA29747 for ; Mon, 13 Dec 2004 13:48:40 +0100 (MET) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBDCmdqp008225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Dec 2004 13:48:40 +0100 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id A930520032; Mon, 13 Dec 2004 13:48:39 +0100 (CET) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29847-01-61; Mon, 13 Dec 2004 13:48:37 +0100 (CET) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id C6AE32001A; Mon, 13 Dec 2004 13:48:37 +0100 (CET) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 9D05126E87; Mon, 13 Dec 2004 13:48:37 +0100 (CET) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id 9482A3D9E; Mon, 13 Dec 2004 13:48:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 912FA2D686; Mon, 13 Dec 2004 13:48:37 +0100 (CET) Date: Mon, 13 Dec 2004 13:48:37 +0100 (CET) From: Thomas Fischbacher To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] environment idiom In-Reply-To: <20041213.210940.74758065.garrigue@math.nagoya-u.ac.jp> Message-ID: References: <20041213.182117.79057361.garrigue@math.nagoya-u.ac.jp> <20041213.210940.74758065.garrigue@math.nagoya-u.ac.jp> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at nez-perce with ID 41BD8FA8.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BD8FA7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 notation:01 haskell:01 notation:01 haskell:01 monadic:01 stomach:98 genius:98 genius:98 hooked:98 cip:98 cip:98 lambda:01 lambda: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: On Mon, 13 Dec 2004, Jacques Garrigue wrote: > > In a certain sense, this "do" notation - which is NOT a special extension > > of the powers of pure, functional haskell but only a short-hand notation > > for things that can be spelled out explicitly - is "poison" that allows > > one to "just hack one's imperative thoughts into haskell without > > even having know about the abstract point of view". > > I wonder whether this is really so. > Some programs without the do notation would be much harder to read. > Do you really think they can all be rewritten to cleaner alternative > code? Deep in my stomach I have the feeling that precisely this is the case, and it might well involve some additional syntactic sugar. The problem is perhaps that the imperative way of coding - which (if we admit it) we all are at least somewhat used to - blocks our view onto more reasonable ways to tackle this issue. As one says, a genius is someone who is the first to do something obvious in the right way, and it will perhaps take a genius to find the proper way to express IO plan composition in a strikingly beautiful way which in particular does not suffer from naive imperative mis-interpretation. At present, it seems as if there were problems of both types: those where most of the desired functionality can be easily expressed in a purely functional way, which is hooked into an otherwise small IO plan, and those where a large and highly sophisticated IO plan makes use of only very few and small purely functional helpers. Somehow, this disparity "feels" quite strange. These are just a few random thoughts on an issue that is perhaps not yet sufficiently well understood to reach a final conclusion. Considering that the monadic point of view only entered the scene quite recently, I hope that in a few years, we have a much better understanding of all these things. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)