[slime-devel] Restart Numbering

[Tobias C. Rittweiler]

Madhu <enometh at meer.net> writes:

> | diff -u slime/ChangeLog:1.1880 slime/ChangeLog:1.1882
> |
> | +2009-10-23  Tobias C. Rittweiler <tcr at freebits.de>
> | +
> | +	Restarts in SLDB are now numbered reversely. The rationale is that
> | +	always-existing restarts are likely to be associated with the same
> | +	number now.
> | +
> | +	* slime.el (sldb-insert-restarts): Number restart reversely.
> | +	(sldb-restart-number-for-swank): New; recompute the unreversed
> | +	number for the swank side.
> | +	(sldb-restart-number-at-point): Previously `sldb-restart-at-point'.
> | +	(sldb-invoke-restart): Adapted accordingly.
>
> I see 2 issues here, but I think the idea is bad for several reasons
> including:
>
> 1. It fails to meet the stated purpose.  Always existing restarts
>    (provided by slime already had the same number); If the goal was to
>    match the order of presentation with what the implementation debugger
>    would provide consider
>
>    Inner restarts have lower numbers than outer restarts. See how
>    implementations number the restarts in
>
>    (with-simple-restart (barf-outer "barf")  (with-simple-restart
>        (foo-inner "foof") (error "bARF")))
>    
>    Every implementation's debugger numbers a restart for FOO-INNER at a
>    smaller number than the restart for BARF-OUTER.  SLDB now reverses
>    this ordering.

I think this is a true complaint for the case when you're used to use
the native debugger equally often as the Slime debugger. I'm eager to
say that this is probably the unusual case for users of Slime, but I'm
solely extrapolating from my own.

>
> 2. Reversing the printed order of restarts means, when you have more
>    than a handful of restarts, you cannot restart 0 or 1 (the "first
>    restart the user would want to invoke"), because it is hidden; SLDB
>    only lists the first few restarts, you have to move the cursor down
>    to the "--more--" button and hit RET to see more restarts. (This
>    slime UI element is an intensely painful part of slime, subject of a
>    different rant).

There's a slight misunderstanding of my change, I think: The restarts
_themselves_ are _not_ reversed, just their numbering is reversed; it's
done this way exactly for reasons of giving importance to locality.

And if you think of it, the reversed numbering actually does make sense
(beyond its technical advantage) as it reflects the stack-like behaviour
of binding.

[I think I agree on the --more-- part, but I don't see it that often
myself. I'd feel content with a keybinding which shows full detail of
the restart list and the backtrace.]


> 3. This is confusing to my muscle memory which has been trained to
>    hitting 0 for the first restart expected from the lisp program being
>    evaluated (an argument i started making in 2008-08-25, but did not
>    complete). Consider the the numeric keypad. However I assume you did
>    want to ensure the restart 0 was `return to slime top-level.')

No not because of that: notice that `q' is bound to "return to
toplevel", and `a' is bound to "invoke abort", and `c' to "invoke
continue".

The point of the change is that the numbering of restarts is almost
static for errors resulting from similiar code paths. Does this make
sense?

Quick example: Slime's RETRY restart which is wrapped around REPL
requests will now always be numbered 2 on SBCL.

  -T.

PS.

Notice that you can easily add your own symbolic bindings for your
application-specific restarts by means of `sldb-invoke-restart-by-name'.