The assumption I did make is that users WILL WANT to invoke innermost restarts more often, and so numbers should be from 0 outwards. I assumed If someone is going to the trouble of wrapping an errorable form in a restart-case, they expect you will want to call _those_ restarts more than someone lower in the call chain. (i.e. someone wrapping a call at a bigger number in the stack backtrace), since this is what error recovery is all about. I'm just going to quibble below: * Levente Mészáros Wrote on Mon, 26 Oct 2009 12:11:38 +0100: |> If you read carefully upthread I've stated in this thread is MY |> experience and MY usage scenario, which I have been carefully |> qualified. What makes you think I've extrapolated anything? | Do you mean this? | | "Even then, the motivation is both bogus and wrong and the design goes | against basic debugger sense which ALL implementations have | implemented!" Apart from the motivation part which was `attitude', I was stating a fact I knew: Slime's new behaviour numbered the restarts in an order that is the reverse of how it is done in every Common Lisp implementation that I've seen so far. Is there a lisp implementation that doses it the other way? | or this? | | "No, I think this is a general design consideration for all those | implementations." This has to do with the fact as before. ALL debugger environments I'VE SEEN SO FAR have done it that way, and I saw good reasons for doing it that way. I thought explained the reasons, without extrapolating! (the numbering matches the contours, inner restarts, growing downwards) | maybe this? | | "If you had tried the old way instead of rewriting it, you would have | liked that too, AND not screwed all other usages." This was a snide remark to tcr. But isnt it trivially true? In reversing the numbering of restarts you have screwed everybody who counts on the innermost restarts getting a 0 number. |> Tobias seems to recognize that the others usage scenarios are results of |> miscoding/not understanding how restart contours work. | It is not only impractical to do what you suggest even within a single | library, but try to do this cross library! I agree that a new variable is the best way to go. Good luck getting helmut to agree though! -- Madhu