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