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 285D2BB81 for ; Mon, 13 Dec 2004 12:46:43 +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 iBDBkggX029713 for ; Mon, 13 Dec 2004 12:46:42 +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 MAA27832 for ; Mon, 13 Dec 2004 12:46:42 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBDBke9F029710 for ; Mon, 13 Dec 2004 12:46:41 +0100 Received: from [192.168.1.200] (ppp209-112.lns2.syd3.internode.on.net [203.122.209.112]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBDBkW7D094188; Mon, 13 Dec 2004 22:16:33 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Thomas Fischbacher Cc: Michael Walter , caml-list In-Reply-To: References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.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> <877e9a170412121109ec02d44@mail.gmail.com> <1102898935.2768.88.camel@pelican.wigram> <877e9a17041212180365f76e4a@mail.gmail.com> <877e9a170412121805295e4704@mail.gmail.com> <877e9a170412121844b633bb8@mail.gmail.com> <877e9a1704121218456af9df9@mail.gmail.com> Content-Type: text/plain Message-Id: <1102938392.2578.138.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Dec 2004 22:46:32 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BD8122.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BD8120.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 wrote:01 abstraction:01 algebra:01 monads:01 contrarily:01 haskell:01 abstraction:01 haskell:01 combinators:01 ocaml:01 formalise:01 imho: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, 2004-12-13 at 19:56, Thomas Fischbacher wrote: > 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, Right. So, how can you distinguish these two ways of programming? I'm not claiming purity, transparency, or monads are bad, contrarily it's great stuff! But as usual, with greater power you lose something. > It's just the same with Haskell and the IO monad. So again the question is -- can you *characterise* better, the good uses and the bad ones? Perhaps you can do this by examining the higher order abstraction being implemented and see if that is transparent or not? With Haskell you have a *formalised* system for building combinators (unlike Ocaml where you can still make them, but it's a technique, not a language feature). Given that you can probably formalise the properties of the machinery you can build with them. The ST monad is so powerful it provides a general way to do procedural programming .. IMHO that isn't at all bad. Not all procedural code is bad :) But the same caveats probably apply to both ordinary procedural code and a monadic version. The main diffence is probably that *todays* Haskell programmers will probably use the monad sparingly, making as much code ordinary functional code as possible. But if you go around yelling 'FP is the magic bullet' and then 'Haskell can do procedural programming too -- but it is magical, when you do it is makes procedural code referentially transparent' .. then what happens? You'll get people that literally translate C code into ST monadic Haskell mechanically and claim their code is better now .. :) Anyhow I don't wish to argue that monads or FP is bad, contrarily, I would like to learn more how to properly characterise properties like transparency -- the ST monad (and IO) clearly show that you can simultaneously have and not have transparency, purity, etc depending on your view. So perhaps you can help define what I mean by view .. because I only have a vague intuition what it means. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net