From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 61AFCBB81 for ; Mon, 13 Dec 2004 13:30:22 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBDCUL3o001807 for ; Mon, 13 Dec 2004 13:30:21 +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 NAA29465 for ; Mon, 13 Dec 2004 13:30:21 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBDCUJeZ001796 for ; Mon, 13 Dec 2004 13:30:20 +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 iBDCUC7D016181; Mon, 13 Dec 2004 23:00:13 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Michael Walter Cc: William Lovas , caml-list In-Reply-To: <877e9a17041213012926f7e18a@mail.gmail.com> References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com> <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> <877e9a170412121109ec02d44@mail.gmail.com> <1102898935.2768.88.camel@pelican.wigram> <877e9a17041212180365f76e4a@mail.gmail.com> <1102916483.2768.204.camel@pelican.wigram> <877e9a17041213012926f7e18a@mail.gmail.com> Content-Type: text/plain Message-Id: <1102941011.2578.182.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Dec 2004 23:30:12 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41BD8B5D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41BD8B5B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 abstraction:01 ocaml:01 ocaml:01 syntax:01 haskell:01 monads:01 conversely:01 glebe:01 061:98 contrast:01 idiom:01 nsw: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 20:29, Michael Walter wrote: > What is "the detail level"? Like the "language level" in contrast to > the level of the current abstraction (for instance, State monad)? Yes, that's the idea. > Different note: I think you are missing out an important property of > the functional encoding, which is its purity wrt composability. Oh no, I'm not missing that! I'm very happily missing the ugly warts of C++ that *stop* me composing things transparently! The fact that Ocaml (and Felix) still allow procedural code means I'm not forced to use functional techniques, but Ocaml at least doesn't prevent me .. and C++ certainly did. > In constrast, in a language such as C++ you cannot assume that.. > vector sieve(unsigned); > has no side effects. Indeed. I am not missing the advantages of transparency, the point I'm making is that even in an FP, when you're considering your code at a higher level than the ground syntax .. you may still lose the functional nature and its advantages. To avoid that I want to know far more precisely how to characterise things . I know what a function is, so the problem is that I do NOT know exactly what 'code' is :) > Also consider the "print" part of your algorithm, which I ignored so > far. In C++ it would be very easy to add it to sieve() thus making the > function virtually useless to use but in the special case where you > want to print the number instantly. > > In Haskell, you *could* have a sieve :: Integer -> IO [Integer], but > what you would really do is to decouple the sieve and I/O And you'd do that in C++ too. Only it would be harder .. > (and this is > made kinda "attractive" by the expressiveness of the language and the > type system). Yes. I'm not saying monads are bad or anything, I'm saying that the dang things are so powerful there is danger of just doing bad old procedural programming with them. And conversely, people hyping FP like OO: I believe a language has to support stateful and functional programming in a balanced way. The fact this is NOT currently the case is due to a deficiency of theory -- it isn't because FP is intrinsically better (just that FP is better understood). -- 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