[slime-devel] Restart Numbering

[Madhu]

* "Tobias C. Rittweiler" <87pr8bd84f.fsf at freebits.de> :
Wrote on Sun, 25 Oct 2009 12:29:36 +0100:
| Madhu <enometh at meer.net> writes:
|
|> * "Tobias C. Rittweiler" <87k4yjeuhl.fsf at freebits.de> :
|> Wrote on Sun, 25 Oct 2009 09:41:10 +0100:
|>
|> [quoting you out of order]
|>
|> | Notice that you can easily add your own symbolic bindings for your
|> | application-specific restarts by means of `sldb-invoke-restart-by-name'.
|>
|> The point is for invoking a restart with a single (or as few keystrokes
|> as possible).
|
| Yes, I meant that you can easily define keybindings to functions which
| use sldb-invoke-restart-by-name. E.g. you could use the Fnn keys.

No, my Fnn and other keys are bound to other things.  I come from CMUCL
where I hit a single digit (a number) to invoke a restart. In this
scheme if I'm facing 10+ restarts, the restart the sldb user gets the
dick. he have to hit 2 digits, 

When I design a nested restart-cases or restart binds for the sldb user,
I want to provide a consistent restart mechanism. I have code where the
innermost restarts always stay the same. However the total number of
restarts may vary. Earlier I could count on the user not having to look
and pick out a number to get atthe innermost restart. Now the user gets
dick, For any restart provided by restart-case he has to READ all
restarts, and pick a number, which is NOT the easiest number to type.
|> No, I think this is a general design consideration for all those
|> implementations. 
|> If you have concentric circles, you start numbering the innermost one 0
|> and the next circle 1 etc.
|
| I'm not sure there really has been given much thought to this. It's more
| likely that implementations just numbered the return value of
| COMPUTE-RESTARTS without a detailed decision making process.

The implementations work as expected when designing nested
RESTART-CASES.

|> If I have several restarts with same name, they all look the same when
|> printed.  Then one would rely on the numbering to determine which is the
|> correct `continue' restart (say) to invoke. This order should not be
|> messed up with
|
| You really orientate yourself on the actual numbers? I orientate myself
| on the order of appearance -- i.e. what comes on top has a more recent
| binding.

Top is always 0. Next is 1, next 2. Stack grows down.


[example snipped, I'll check maybe next month]

| Yeah, that's why I suggest to to solidify the interface with custom Fnn
| bindings and not to rely on the order. (Fnn bindings on top of
| invoke-restart-by-name would of course always invoke the most recently
| established restart -- dunno if you actually tend to have lots of
| identically-named restart at the same time.)

No, I want to use digits.  I need all other keys for other purposes.
The argument applies against your change: Can't you just use a custom
Fnn binding for the RETRY-RESTART is so important instead of messing
with the restart order supplied from the implementation?

| Ah. Yes, I can see your point now. OTOH, the new behaviour does have a
| technical advantage (see below) and, while it's probably true that if I

No I cant see it. Really.

| had been accustomed to the old way as much as you, I wouldn't have made
| the change. So, erm, this kind of boils down to: "Sorry that I've
| screwed you, but I haven't screwed me, and I like the new way."

more like `I invented the new way so I like it.'  If you had tried the
old way instead of rewriting it, you would have liked that too, AND not
screwed all other usages. 

--
Madhu