[slime-devel] Restart Numbering

[Tobias C. Rittweiler]

Helmut Eller <heller at common-lisp.net> writes:

> * Tobias C. Rittweiler [2009-10-25 09:41+0100] writes:
>
>>> 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.
>
> An argument could be made that the hot end of the stack is more
> important and that the good keys should be used for the top of the
> stack.

> I can see that quickly accessible restarts at the bottom are nice too
> but Slime has keys for those already.  Why then burn all keys for the
> bottom?

It's not about making the restarts at the bottom quickly accessible
(they mostly are already due to q,a,c), and it's not about the RETRY
restart, it's about _fixing_ the numbering for code that share the same
code-path.

E.g. to expand on the example I gave to Madhu:

  (defun application (cont)
    (with-simple-restart (APP-R1 "Application restart 1")
      (with-simple-restart (APP-R2 "Application restart 1")
        (funcall cont))))

Old:

  > (application #'(lambda () (error "An error")))

  An error
     [Condition of type SIMPLE-ERROR]

  Restarts:
   0: [APP-R2] Application restart 1
   1: [APP-R1] Application restart 1
   2: [RETRY] Retry SLIME REPL evaluation request.
   3: [ABORT] Return to SLIME's top level.
   4: [TERMINATE-THREAD] Terminate this thread (...)

  > (application #'(lambda () (cerror "Frob!" "An error")))

  An error
     [Condition of type SIMPLE-ERROR]

  Restarts:
   0: [CONTINUE] Frob!
   1: [APP-R2] Application restart 1
   2: [APP-R1] Application restart 1
   3: [RETRY] Retry SLIME REPL evaluation request.
   4: [ABORT] Return to SLIME's top level.
   5: [TERMINATE-THREAD] Terminate this thread (...)


As you can see, the application restarts were all renumbered. And in
past you had to carefully look at the restart list to choose the right
restart.


New:

  > (application #'(lambda () (error "An error")))

  An error
     [Condition of type SIMPLE-ERROR]

  Restarts:
   4: [APP-R2] Application restart 1
   3: [APP-R1] Application restart 1
   2: [RETRY] Retry SLIME REPL evaluation request.
   1: [ABORT] Return to SLIME's top level.
   0: [TERMINATE-THREAD] Terminate this thread (...)

  > (application #'(lambda () (cerror "Frob!" "An error")))

  An error
     [Condition of type SIMPLE-ERROR]

  Restarts:
   5: [CONTINUE] Frob!
   4: [APP-R2] Application restart 1
   3: [APP-R1] Application restart 1
   2: [RETRY] Retry SLIME REPL evaluation request.
   1: [ABORT] Return to SLIME's top level.
   0: [TERMINATE-THREAD] Terminate this thread (...)


In the new numbering, the application restarts (as they're established
within the same code path) will be associated with the same numbers. 

If, now, you know that an error came from the same code path (often the
case when you're interactively writing some part of your application),
you can develop a good sense how restarts are numbered.

  -T.