Use of continuations in eval traps

Use of continuations in eval traps

[Neil Jerram]

Hi Mikael,

I'm writing directly to you (CC guile-devel) because I believe you
originally implemented the low level traps in eval.c - please correct
me if that's wrong.

I'm thinking about how to implement the ability to skip over the
evaluation of an expression, and providing an easy interface for use
in my Emacs front end, and wondering whether the existing
continuation-based approach is really needed.  The problem with the
continuation approach (in other words, whenever the 'cheaptraps option
is off) is that a continuation is set up before every trap call even
though it won't be needed in most cases, and it seems to me that one
could get similar function by passing the expression to evaluate into
the trap handler and allowing the trap handler to modify it (either by
side effect or by return, to be determined).

If I'm right, it also follows that we could remove the 'cheaptraps
option and use debug-objects unconditionally for these trap calls.
Note that the trap handler remains free to save off its continuation
itself, if that is useful.

What do you think?

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Use of continuations in eval traps

[Mikael Djurfeldt]

On 10/28/05, Neil Jerram <neil@ossau.uklinux.net> wrote:
> I'm writing directly to you (CC guile-devel) because I believe you
> originally implemented the low level traps in eval.c - please correct
> me if that's wrong.

No, that's right.

> I'm thinking about how to implement the ability to skip over the
> evaluation of an expression, and providing an easy interface for use
> in my Emacs front end, and wondering whether the existing
> continuation-based approach is really needed.  The problem with the
> continuation approach (in other words, whenever the 'cheaptraps option
> is off) is that a continuation is set up before every trap call even
> though it won't be needed in most cases, and it seems to me that one
> could get similar function by passing the expression to evaluate into
> the trap handler and allowing the trap handler to modify it (either by
> side effect or by return, to be determined).
>
> If I'm right, it also follows that we could remove the 'cheaptraps
> option and use debug-objects unconditionally for these trap calls.
> Note that the trap handler remains free to save off its continuation
> itself, if that is useful.
>
> What do you think?

You are probably more competent to answer the question than me.

I wrote that code when I was pretty inexperienced, and the choice to
allow for the continuation to be saved was probably more motivated by
a feeling that I didn't want any limitations on what you could do with
traps than anything more specific---except that I probably had
imagined the continuations as a way to resume execution after a
breakpoint, of course.

I agree that it seems expensive to create the continuation at every
trap, and your idea to skip the cheaptraps option and delegate the
decision whether to create the continuation or not to the lazy handler
code (I assume) seems good.

Unfortunately I can't say anything more constructive than that because
I'm not up-to-date with the code.

BTW, your work on the debugger and Emacs interface seems really great---thanks!

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Use of continuations in eval traps

[Neil Jerram]

Mikael Djurfeldt <mdjurfeldt@gmail.com> writes:

> You are probably more competent to answer the question than me.

:-)  Well thanks for your quick response anyway; it's very helpful.

> I wrote that code when I was pretty inexperienced, and the choice to
> allow for the continuation to be saved was probably more motivated by
> a feeling that I didn't want any limitations on what you could do with
> traps than anything more specific---except that I probably had
> imagined the continuations as a way to resume execution after a
> breakpoint, of course.

Oh yes, I remember now; continuations have not been necessary for
continuing after a breakpoint since this change to call the trap
handlers directly instead of executing a throw:

2001-06-26  Neil Jerram  <neil@ossau.uklinux.net>

	* eval.h, eval.c (scm_call_4): New function.

	* eval.c (SCM_APPLY, SCM_CEVAL, ENTER_APPLY): Call trap handlers
	directly rather than dispatching to them via scm_ithrow and a lazy
	catch.

	* eval.c (scm_evaluator_trap_table), eval.h (SCM_ENTER_FRAME_HDLR,
	SCM_APPLY_FRAME_HDLR, SCM_EXIT_FRAME_HDLR): Add three new options
	for trap handler procedures.

	* debug.h (SCM_RESET_DEBUG_MODE): Add checks for trap handler
	procedures not being #f.

(I hope I didn't miss anything by making this change ... I think I
checked it with you at the time also.)

> I agree that it seems expensive to create the continuation at every
> trap, and your idea to skip the cheaptraps option and delegate the
> decision whether to create the continuation or not to the lazy handler
> code (I assume) seems good.

Cool, I'll give it a go and see what turns out.

> BTW, your work on the debugger and Emacs interface seems really great---thanks!

Thanks again,

       Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel