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 6920ABB81 for ; Mon, 13 Dec 2004 08:08:38 +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 iBD78bHq018891 for ; Mon, 13 Dec 2004 08:08:38 +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 IAA18925 for ; Mon, 13 Dec 2004 08:08:37 +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 iBD78Z2m018876 for ; Mon, 13 Dec 2004 08:08:36 +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 iBD78U7D056197; Mon, 13 Dec 2004 17:38:30 +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: <1102918715.2768.240.camel@pelican.wigram> 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> <1102918715.2768.240.camel@pelican.wigram> Content-Type: text/plain Message-Id: <1102921708.2768.282.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Dec 2004 18:08:30 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BD3FF5.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BD3FF3.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 ocaml:01 unification:01 overloading:01 subtyping:01 lazy:01 compiler:01 model:01 lazy:01 interacts:01 glebe:01 061: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: On Mon, 2004-12-13 at 17:18, skaller wrote: BTW: one reason I'm very interested in the 'transparency' and 'purity' topic is a practical matter: > 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 ..] Crudely the optimiser simply inlines everything, perhaps an improved version will do usage checks to cache results.. This must work fine if functions are pure. But as noted, they're not, because they can access variables that change with time, and so the place of calling a function, which is related to when it is evaluated, makes a difference. To fix this I need to be able to do something crude like designate a function as 'pure' -- this has been discussed for Ocaml too. That isn't the only possible technique, and it isn't clear how to carry this information through for function variables, unless the type system is involved. EG you have two arrows: a -> b pure function a +> b can refer to variables which raises questions about unification, overloading, subtyping, etc. However if a function isn't pure, when you evaluate it matters .. but that doesn't tell you when to evaluate it. Instead of saying 'strict' or 'lazy', one could annotate function arguments: let f (g:lazy) (h:eager) (k:pure) x = .. which tells the compiler that to evaluate h 'before the call', g precisely when needed, possibly twice with different results, and k anytime convenient. Well that seems to impact the type system too.. :) At present I use a trick to distinguish procedures: they have the type 'a -> void which prevents them being used in a context where the sequence of evaluation is indeterminate (i.e. in expressions). Well now I seem to need more than just procedures and functions, I need at least pure and impure functions (where impure does NOT mean side-effects, but rather non-parametricity, which has the same negative effect on transparency). So I have a pragmatic interest in finding a theoretical model that says something more about how pure/impure/lazy/eager/etc etc code interacts: with the optimiser switched on, I'm the only person that can predict what a Felix program will do, and my own optimiser has caught me out several times already :) -- 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