Re: Evaluating (exit) in the debugger

["Neil Jerram" <neiljerram@googlemail.com>]

Hi Derek,

I'm sorry that my followups to you are so slow, and hope that this
hasn't resulted in unnecessary work...

2008/11/21 Derek Peschel <dpeschel@eskimo.com>:
> On Fri, Nov 21, 2008 at 12:09:18AM +0000, Neil Jerram wrote:
>> I'm afraid I don't understand.  What do you want to happen when you
>> type "e (exit)"?
>
> I want Guile to exit, just as normally happens when you call (exit).
>
> Also return codes should be supported in the debugger as in the REPL,
> e.g. "e (exit 5)" should return 5 to the calling UNIX process.

(primitive-exit RETURN-CODE) will do both of those.

I'm afraid I can't remember why (exit ...) in Guile is actually just
(throw 'quit ...), but it's been that way for a long time now, so
might be difficult to change.

> The principle is that the debugger should not interfere with the
> actions of code it's debugging, which to me includes "e"'d code.

Interesting.  But on the other hand, we don't want unintended errors
in "e"'d code to propagate back into the actual program!  Is there any
nice general way of distinguishing between intentional exceptions
(which should not be caught by eval-handler) and unintended ones
(which should be)?

> And I need to work out how many levels of handler are running when the
> evaluation happens.  I wonder if Guile can tell me that?

It's possible in principle, but I don't believe we currently have a
primitive to expose this (i.e. the value of scm_i_dynwinds ()) to the
Scheme level.  If we did expose this, I think we should do so in a way
that still allows us to change the internal representation of the wind
list, without any back-compatibility problems.

Regards,
       Neil