English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] Error Reporting
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-10-01 (15:53)
From: David McClain <barabh@q...>
Subject: Re: [Caml-list] Error Reporting
Ah yes! I remember that Flanagan paper. Now maybe I can really try to
understand it. I really appreciate all your feedback and the pointer to the
surrounding context papers.

I am compiling to OCaml closures. And for the most part the translation is
direct. However, I found that the compilation of match clauses benefited
greatly from CPS style.

I actually did one version of the compiler that used CPS throughout and I
found that I could almost do that except for the management of the OCaml
exception frames. But I also found that the code tended to run about 30%
slower (test programs took 1.3 times longer to run). The bulk of the code
was not measured, but your papers indicate that CPS is a bit of a memory

Many thanks to all who responded!

- DM

----- Original Message -----
From: "Frank Atanassow" <franka@cs.uu.nl>
To: "David McClain" <barabh@qwest.net>
Cc: <caml-list@inria.fr>
Sent: Monday, October 01, 2001 7:17 AM
Subject: Re: [Caml-list] Error Reporting

> David McClain wrote (on 28-09-01 09:49 -0700):
> > > There must be a past history, or otherwise you would not be able to
> > > 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
> > 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
> of the application term to the operator, because the result of the
> has to be returned to the context of the call. That continuation is your
> 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
> 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
> 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
> transform, for example by turning continuations into an abstract datatype
> 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,
> 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
> 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