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 2D8DABB81 for ; Sun, 12 Dec 2004 00:57:17 +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 iBBNvG3E004018 for ; Sun, 12 Dec 2004 00:57:16 +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 AAA03710 for ; Sun, 12 Dec 2004 00:57:16 +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 iBBNvEW4024737 for ; Sun, 12 Dec 2004 00:57:15 +0100 Received: from [192.168.1.200] (ppp203-65.lns1.syd3.internode.on.net [203.122.203.65]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBBNud7D001861; Sun, 12 Dec 2004 10:26:56 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Markus Mottl Cc: Andrej Bauer , caml-list In-Reply-To: <20041211181313.GA9656@fichte.ai.univie.ac.at> 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> Content-Type: text/plain Message-Id: <1102809398.2611.637.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 12 Dec 2004 10:56:38 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BB895C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41BB895A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 markus:01 mottl:01 wrote:01 monadic:01 implicitly:01 statically:01 arrays:01 mutable:01 haskell:01 monads:01 monads:01 haskell:01 monadic: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 Sun, 2004-12-12 at 05:13, Markus Mottl wrote: > Another solution would be to use a state monad encapsulating > the environment. It has operators for getting and setting states. > Instead of passing all arguments from function to function "manually", > you then just need to use the monadic bind operator, which does all that > implicitly - and even purely functionally + in a statically type safe way! There's some illusion here. I had an argument with someone that functional arrays were impossible: array implies O(1) which implies mutable. Yet Haskell has them, via monads .. and it's all 'purely functional and referentially transparent'. Took me a while to figure out why this is NOT the case. Yet obviously, it cannot be. Consider a more extreme example: using state transformer monads, you can emulate the action of any C program in Haskell. So it is quite clear there's no possibility of this being 'purely functional and referentially transparent' because C programs are not. The answer is evident in this example because it is so extreme. Whether code is 'purely functional' etc or not, is a matter of your viewpoint. Sure, the *Haskell* encoding is purely functional, but the code *viewed at the monadic level* is not. I.e. if you implement an interpreter for a non-transparent non-functional language in a transparent and functional one, then the interpreter is purely functional, but what it interprets is not. So monadic programming with state transformers is NOT referentially transparent or purely functional at all. Because you are NOT encoding in Haskell but using the extension the monad provides.. and THAT code patently isn't functional. So actually all these claims about purely functional I/O and state transformers are wrong: they miss the fundamental point that when you use them you're no longer coding in the base language -- the notion of 'code' is relative. In the 'C interpreter' monad your code has all the same properties C has -- in particular it isn't transparent or purely functional. The fact that the interpreter implementation retains these properties is only relevant to the correctness of the interpeter -- not the use of it. I think there is a theorem here: when you abstract purely functional code, there is no guarrantee the result is functional. The bottom line is that given an environment E f: A -> B is not functional if f fiddles with environment E. It is absurd then to think that f: E * A -> E * B is suddenly purely functional, just because the environment is now made explicit. This is the inverse theorem: you can lift any non-functional code to a purely functional interpretation. Monads just 'drop' the explicit E, leaving the orginal f which is not functional by specification. Contradiction: monadic extensions of Haskell do not magically allow purely functional arrays. But it is all just fiddling with the 'level' of the code you're talking about. Fundamentally the notions of purely functional and referentially transparent are relative things. Your Haskell is running on a CPU that clearly isn't functional. A final example. Ocaml *is* purely functional. As long as you consider references as values -- rather than what they refer to. In reality, it's just a state transformer monad like Haskell, only the encoding is built in to the language. -- 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