Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: -- (:)
From: David McClain <barabh@q...>
Subject: Re: [Caml-list] Error Reporting
Er... sorry, I really hosed up the CPS translation...

> 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...

Let's take a trivial example of a sequence of 3 "primitive" operations -- a
primitive operation being one which cannot make use of a continuation

Normal OCaml syntax for such a function would be:

let seqFn () =
    aFn ();
    bFn ();
    cFn ()

Now let's write what the compiler would translate this into....

let cPart () kont =
     cFn ();
     kont ()

let bPart () kont =
    bFn ();
    cPart () kont

let aPart () kont =
    aFn ();
    bPart () kont

The compiler returns the "aPart" closure as the toplevel result of compiling
the seqFn. The kont argument of the toplevel call, at runtime, represents
the continuation that should be jumped to after the entire seqFn equivalent
has executed. But continuations are always forward pointing links to program
history and never backward links. Without a stack and normal function
subroutine calls there is no place for execution history.

Here you see that all continuations are executed as tail jumps without
leaving an audit trail of history. Each subfunction stands alone and knows
nothing of the others. All any of them know is what they must do for their
part, and what continuation to jump to to finish up the program.

So now, if an error occurs in any of these inner closures, how will they be
able to report the chain of events leading to their execution?

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.


- DM

----- Original Message -----
From: "Frank Atanassow" <>
To: "David McClain" <>
Cc: <>
Sent: Friday, September 28, 2001 8:24 AM
Subject: Re: [Caml-list] Error Reporting

> David McClain wrote (on 27-09-01 13:36 -0700):
> > In a tail call, and all continuations are tail calls, there is no record
> > past history -- hence no trail of continuation frames. I can easily
> > the location of the present error, but there is no history to report.
> There must be a past history, or otherwise you would not be able to
> function application.
> Let's make a distinction between continuations and tail calls. Really, it
> sounds like you are only _representing_ continuations in the source
> as tail calls in the target language. So in the target language, the two
> identified, but when you are compiling the source, you know which
> continuations are tail-recursive calls in the source language, and which
> only functional returns. In the code you emit, i.e., in the target
> language, you can thus distinguish these two types of continuations, and
when an
> error occurs, traverse the continuations which represent functional
> which should eventually lead to the prime mover, the entire program's
> continuation.
> --
> 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:  FAQ:
> To unsubscribe, mail  Archives:
Bug reports:  FAQ:
To unsubscribe, mail  Archives: