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 F29F8BB81 for ; Mon, 13 Dec 2004 13:09:46 +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 iBDC9kN4001191 for ; Mon, 13 Dec 2004 13:09:46 +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 NAA28208 for ; Mon, 13 Dec 2004 13:09:45 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBDC9hbM001178 for ; Mon, 13 Dec 2004 13:09:45 +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 iBDC9gd3008481; Mon, 13 Dec 2004 21:09:42 +0900 (JST) Date: Mon, 13 Dec 2004 21:09:40 +0900 (JST) Message-Id: <20041213.210940.74758065.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: <20041213.182117.79057361.garrigue@math.nagoya-u.ac.jp> X-Mailer: Mew version 4.1 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 41BD868A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BD8687.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 monadic:01 closures:01 monads:01 haskell:01 abstractions:01 computations:01 haskell:01 notation:01 notation:01 monadic:01 minor:01 monads:01 attitude:98 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 Mon, 13 Dec 2004, Jacques Garrigue wrote: > > > > 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. > > First, I should perhaps mention that in my point of view, John does have a > valid point in what he says. It's only that he expressed it in a way I > just *cannot* agree with. OK, so probably we almost agree. Three days ago I was about to answer John that indeed he has a good point, but he seems to ignore completely the other advantages of monads, like the fact you can cleanly mix stateful code with pure code, keeping the two separate. > > So what is so incredible about the IO monad? > > There is nothing "in-credible" about it. It is just plainly nothing else > as working with values that describe "plans" to do IO. We do have a magic > place that can bring such plans to life, causing them to be executed, but > from the pure Haskell point of view this is not relevant. All we do is to > construct plans how to do IO. So maybe the problem goes back to the compositional vs. pointwise view of things. While the compositional view is nice, at some level of detail I find it simpler to reason pointwise (even when purely functional). My real curiosity was about the kind of compositional abstractions one would use with stateful computations. It seems to me that the presence of state itself makes it more difficult to compose cleanly. At least, types help you less: they let you now that there is state around, but not the detail of how this state is used (maybe I'm not up-to-date with recent Haskell.) > > Of course according to your definition this contains nothing that is > > not referentially transparent once you've taken the syntactic sugar. > > Precisely. To go a bit more into detail: No need to explain: I know this is referentially transparent :-) My only point was that it doesn't _look_ so. > 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". This is a bit like > FORTRAN programmers asked to adjust themselves to C showing the attitude > that "at least, they can forget all that for/while/etc. mumbo-jumbo and > do everything with goto, as they are used to". 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? > Coming back to the original question, which was whether one may "just > stick in some monadic stuff to get a notion of an `environment'", I'm > inclined to say that from the purely functional point of view, this > perhaps is not a good idea, as this is not just "a minor change to the > code" but changes pretty much anything of its original properties. Having worked on parameterization systems a long time ago, I can only agree. The trouble with the monadic view of environment is that you quickly end up making all your functions monadic, introducing some sequentiality which may have no reason to be. While being no expert of the question, this seems to be a tendency of monads: they are so comfortable that they tend to pollute everything, diluting the advantage of knowing exactly what is functional. But how can you stop people from going the easy way? Jacques Garrigue