From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA00855; Mon, 1 Oct 2001 16:18:00 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 QAA00858 for ; Mon, 1 Oct 2001 16:17:58 +0200 (MET DST) Received: from mail.cs.uu.nl (sunset.cs.uu.nl [131.211.80.32]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f91EHwr23365 for ; Mon, 1 Oct 2001 16:17:58 +0200 (MET DST) Received: from silvester.cs.uu.nl (silvester.cs.uu.nl [131.211.80.119]) by mail.cs.uu.nl (Postfix) with SMTP id C27B94533; Mon, 1 Oct 2001 16:17:57 +0200 (MET DST) Received: by silvester.cs.uu.nl (sSMTP sendmail emulation); Mon, 1 Oct 2001 16:17:57 +0200 Date: Mon, 1 Oct 2001 16:17:57 +0200 From: Frank Atanassow To: David McClain Cc: caml-list@inria.fr Subject: Re: [Caml-list] Error Reporting Message-ID: <20011001161757.A29127@cs.uu.nl> References: <004401c1483d$8d1bd160$210148bf@dylan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004401c1483d$8d1bd160$210148bf@dylan>; from barabh@qwest.net on Fri, Sep 28, 2001 at 09:49:33AM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk David McClain wrote (on 28-09-01 09:49 -0700): > > There must be a past history, or otherwise you would not be able to implement > > function application. > > I must confess that I don't understand this statement... [..] > But I suppose you are hinting that the compiler knows that all three of > these closures are contained in the outermost one and so some record of > activation history could be maintained by the compiler secretly plating > static linkage information into each sub-closure. Not a bad idea! It > certainly beats runtime computation of dynamic linkage and storing all that > in a history queue. Something like that. John Prevost gave a nice example. In the CPS transform, in the case for application, you pass the continuation of the application term to the operator, because the result of the application has to be returned to the context of the call. That continuation is your past history, since it tells you where you were before the function body was evaluated. In the case for a tail call, you don't return to the calling context; that is, you discard the current continuation. Instead, (I think) you just pass the function to itself, since so it serves as its own continuation. So, for example, in let rec f x = if x=0 then 1 + g x else f (x-1) you translate g x as [g x] = fun k -> [g] (fun g' -> [x] (fun x' -> g' k x')) but f (x-1) as [f (x-1)] = fun _ -> [f] (fun f' -> [x-1] (fun x' -> f' f' x')) Err... approximately at least. :) You will have to double-check this, but the point is that distinction between these two cases gets obliterated in the image of the translation, because no function _ever_ returns (as you said). Therefore, you have to add the error-handling information before you do the transform, for example by turning continuations into an abstract datatype like John did. Indeed, this is what you have to do anyway when you use CPS to compile to machine code, since machines don't understand lambda-calculus, but I assume you are compiling to Ocaml source. Anyway, you might want to read this paper: The Essence of Compiling with Continuations Flanagan, Sabry, Duba, Felleisen http://citeseer.nj.nec.com/174731.html which shows why CPS transformation is redundant, and it is better to do a source-to-source transformation anyway. If you are really serious about this, then you may also wish to check the Context (papers which reference this paper) to see extensions of this idea. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr