Version française
Home     About     Download     Resources     Contact us    
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
implement
> 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
argument.

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.

Thanks,

- DM



----- Original Message -----
From: "Frank Atanassow" <franka@cs.uu.nl>
To: "David McClain" <barabh@qwest.net>
Cc: <caml-list@inria.fr>
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
of
> > past history -- hence no trail of continuation frames. I can easily
report
> > 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
implement
> function application.
>
> Let's make a distinction between continuations and tail calls. Really, it
> sounds like you are only _representing_ continuations in the source
language
> as tail calls in the target language. So in the target language, the two
are
> identified, but when you are compiling the source, you know which
> continuations are tail-recursive calls in the source language, and which
are
> 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
returns,
> 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: 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
-------------------
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