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 8D587BB81 for ; Mon, 13 Dec 2004 13:59:33 +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 iBDCxXwx010308 for ; Mon, 13 Dec 2004 13:59:33 +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 NAA30399 for ; Mon, 13 Dec 2004 13:59:32 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBDCxUqC006999 for ; Mon, 13 Dec 2004 13:59:31 +0100 Received: from [192.168.1.200] (ppp209-112.lns2.syd3.internode.on.net [203.122.209.112]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBDCxN0r054753; Mon, 13 Dec 2004 23:29:25 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Michael Walter Cc: caml-list In-Reply-To: <877e9a17041213015616bff817@mail.gmail.com> References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com> <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> <1102918715.2768.240.camel@pelican.wigram> <877e9a17041213015616bff817@mail.gmail.com> Content-Type: text/plain Message-Id: <1102942763.2578.213.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Dec 2004 23:59:23 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BD9235.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41BD9232.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 invocations:01 stack:01 threads:01 stack:01 accessors:01 semantics:01 main':01 monads:01 haskell:01 monads:01 computations: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 Mon, 2004-12-13 at 20:56, Michael Walter wrote: > > Another example is my Felix language. It has both functions > > and procedures. Functions aren't allowed to have side effects, > > yet they're not pure in the sense the result can depend > > on variables which change between (but not during) invocations. > > [This has an alarming effect on the optimiser ..] > Can I read about the reasoning behind this on felix.sf.net? No, I haven't really spent enough time on documenting rationale yet. At least one excuse is that the system is experiemental, and another is that, in fact, this particular division of labour proves to have a major deficiency. A crude reason is: procedures don't use the machine stack, which is a requirement for the microthreading to work. Felix can run 1Meg threads on a small Linux box with O(1) context switching. OTOH, I decided functions should not be allowed to have side-effects, for the usual reasons: referential transparency, optimisation, etc. But they use the machine stack: two reasons being performance and ability to integrate with C code. The problem is that side-effect free is only equal to pure in the total absence of any procedural code. Otherwise you have two kinds of functions -- pure ones that don't look at variables, and dirty ones that do. Dirty functions are of course quite useful -- accessors for objects for example, and freedom from side-effects is still useful. But I have to separate the two kinds or the optimiser can't work, and I can't define any sane semantics. > > [...] Clearly you can reason about the > > 'functional subsystem' using transparency, and then combine > > the result with reasoning about the top level 'magic main' > > where the program as a whole is not transparent ... and you still > > have 'ease of reasoning' in the combination. > Indeed (and Monads give you an attractive way to partly do this the > other way around). Yes Indeed!! Duality! > Are there specific statements, for instance on the Haskell home page, > which you dislike? I haven't looked :) > Or do you dislike that fact that for instance in > the statement "Monads allow for sideeffect free encoding of stateful > computations" everyone is assuming that "encoding" refers to the > encoding in the target language? Yes, that's roughly the thing. The point being that this really isn't enough. The problem isn't isolated to monads. That's only syntactic sugar after all -- the issue relates to *all* functional programming, it's just clearer to see with monads, particularly if you compare monadic code with a more conventional interpreter (eg a Haskell interpreter for Perl .. when you execute the Perl is it functional or procedural). The thing is that high level language are 'just syntactic sugar' for assembler .. the point being it just isn't enough to talk about 'the program is functional', rather you need to say 'the encoding is functional at the Haskell level and also at the first major abstraction level but stateful at the third level' or something like that .. and the question is, how should I *really* say that? . > Okay, I was thinking (along the lines of the paragraph above) that you > were unhappy about the way that people are talking about monads. I am, because it confuses me! Their claims are clearly both right and wrong! But I don't have the intellectual apparatus to explain how this can be precisely. Or even crudely :) > Okay. So far I have never been confused by such statements about > monads -- it was usually pretty clear what "pure" was referring to Yeah, but that's the problem: the implication is that it is enough to just refer to the detail level. But that isn't so, because a heavy user of the ST monad might just as well stick with C. They may think they're gaining something that they're not gaining. But there is a converse! Not all stateful code is hard to reason about. In fact by duality, some ways of stateful programming -- yet to be understood -- are just as good as functional coding. Which ones? I don't know but monads seem to offer clue! Crudely, if your stateful program is turned into a Haskell one using 'the least possible ST monadic code', your program is probably sweet. You were probably emulating functional code in procedural code :)) -- 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