Hi List,
In reference to my question about the debugger in regards to Chronology-Core-dtl.80, I have a proposal.
I am halfway or so to stealing RESTART from Common Lisp for Squeak. It lets the programmer define alternatives for exception handling. Restarts would be responsible for making the Proceed, Abandon, etc. buttons in the debugger window, with every #on:offer: defining a button.
It's an extra layer of indirection and complexity in the evaluator, but it is an extremely powerful tool for writing clean code. If I had to choose one of an interactive debugger or restarts I'd pick restarts.
Implementation is easy but tedious... restarts have lots of optional parameters. If List thinks RESTART would be a good thing to have I will prioritize it.
PS: Whoever wrote the signalling code, thank you. It is very clean and easy to read. I learned everything about dynamic extent in Smalltalk from reading it.
Hi Lauren,
Squeak Exceptions have a resumption mechanism. See Exception>>#resume:, or ProvideAnswerNotification and BlockClosure>>#valueSupplyingAnswers: for a common example.
There is no UI integration for this, yet. However, this idea already has been mentioned on the list earlier, this would definitely be a sweet feature. Note that for #notYetImplemented, #doesNotUnderstand:, et al., the debugger already defines a variable button. See senders of #createImplementingMethod. However, this mechanism has not yet been generalized, i.e., by dispatching it to the original exception.
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Lauren P drurowin@gmail.com Gesendet: Montag, 28. November 2022 17:49:01 An: The general-purpose Squeak developers list Betreff: [squeak-dev] wrt debugger flexibility
Hi List,
In reference to my question about the debugger in regards to Chronology-Core-dtl.80, I have a proposal.
I am halfway or so to stealing RESTART from Common Lisp for Squeak. It lets the programmer define alternatives for exception handling. Restarts would be responsible for making the Proceed, Abandon, etc. buttons in the debugger window, with every #on:offer: defining a button.
It's an extra layer of indirection and complexity in the evaluator, but it is an extremely powerful tool for writing clean code. If I had to choose one of an interactive debugger or restarts I'd pick restarts.
Implementation is easy but tedious... restarts have lots of optional parameters. If List thinks RESTART would be a good thing to have I will prioritize it.
PS: Whoever wrote the signalling code, thank you. It is very clean and easy to read. I learned everything about dynamic extent in Smalltalk from reading it.
-- Obviously, I vote yes, and the effort to not proselytize the Cult Of Restart here is great indeed.
Hi Christoph,
Note that restarts are more flexible than just resuming an exception because they can unwind the stack and restart at a different site than where signal was sent to the exception. Say, after a download failed, you could not only resume in the place after it has already happened, but you could restart at the point before the connection is made or change the URL...
Kind regards, Jakob
Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de schrieb am Mo., 28. Nov. 2022, 18:30:
Hi Lauren,
Squeak Exceptions have a resumption mechanism. See Exception>>#resume:, or ProvideAnswerNotification and BlockClosure>>#valueSupplyingAnswers: for a common example.
There is no UI integration for this, yet. However, this idea already has been mentioned on the list earlier, this would definitely be a sweet feature. Note that for #notYetImplemented, #doesNotUnderstand:, et al., the debugger already defines a variable button. See senders of #createImplementingMethod. However, this mechanism has not yet been generalized, i.e., by dispatching it to the original exception.
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Lauren P drurowin@gmail.com *Gesendet:* Montag, 28. November 2022 17:49:01 *An:* The general-purpose Squeak developers list *Betreff:* [squeak-dev] wrt debugger flexibility
Hi List,
In reference to my question about the debugger in regards to Chronology-Core-dtl.80, I have a proposal.
I am halfway or so to stealing RESTART from Common Lisp for Squeak. It lets the programmer define alternatives for exception handling. Restarts would be responsible for making the Proceed, Abandon, etc. buttons in the debugger window, with every #on:offer: defining a button.
It's an extra layer of indirection and complexity in the evaluator, but it is an extremely powerful tool for writing clean code. If I had to choose one of an interactive debugger or restarts I'd pick restarts.
Implementation is easy but tedious... restarts have lots of optional parameters. If List thinks RESTART would be a good thing to have I will prioritize it.
PS: Whoever wrote the signalling code, thank you. It is very clean and easy to read. I learned everything about dynamic extent in Smalltalk from reading it.
-- Obviously, I vote yes, and the effort to not proselytize the Cult Of Restart here is great indeed.
Christoph (and anyone else with this reaction),
On 11/28/22 17:30, Thiede, Christoph wrote:
Squeak Exceptions have a resumption mechanism. See Exception>>#resume:, or ProvideAnswerNotification and BlockClosure>>#valueSupplyingAnswers: for a common example.
The name RESTART took me a couple tries to figure out. Obviously, there is a #resume: function in the exception system. I like 'restart normal evaluation after handling an exception' better, but it doesn't roll off the tongue, and I didn't write the Common Lisp spec, so we're stuck with it.
Let me see if I can explain it better than ice cream sundaes with Jakob's download example...
~ ~ ~ ~ ~ ~ The short version: exception handlers let signallers talk to callers, and restarts let the callers talk back. ~ ~ ~ ~ ~ ~
You write a package that downloads a file. The download can fail, so what should you have the package do? Some users want to give up, others try again, and even others resume it where it left off, so which option do you pick?
All three, of course!
There's a method that knows how far into the download it's gotten. From there you offer 'Resume Download' that works the HTTP 2 magic. Maybe the internet had a hiccup. Maybe your cat sat on your laptop lid because she learned you need what's on the bottom and she wants attention. But first you need to reopen the TCP socket.
We all know Abandon. Abandon is provided for you. But there's another Abandon: if you're loading that download into an instance and the user wants to 'Abandon Loading' you null out whatever incomplete state you were building so that some later check will see, 'Ya... this is null... It never got fetched.' and not 'What is ''828734t9tg9g9ubiuviub3r''?...'.
Then comes Retry. In a different package that works with git, the user sees the reason it failed is they missed the last character during copy-paste. After a duh moment they change the URL and tell it to try that again. Just like Abandon, there are also two Retry options. 'Is it plugged in?' is an amazing question... no wonder it didn't work!
Restarts are all about giving those options. That's why I named the message #on:OFFER:. It's an offer of some action to take. What's more, since these options cause branches in different methods... in different packages... and might be at the whim of the person in front of the screen... they go beyond the capabilities of only condition handlers.
Sadly, that's more complicated than making a yummy ice cream sundae, but it's a good use case.
There is no UI integration for this, yet. However, this idea already has been mentioned on the list earlier, this would definitely be a sweet feature.Two sweets is better than, 'Oh yea... Trait...'. ;3
Lauren Pullen drurowin@gmail.com schrieb am Di., 29. Nov. 2022, 04:45:
What's more, since these options cause branches in different methods... in different packages... and might be at the whim of the person in front of the screen... they go beyond the capabilities of only condition handlers.
Yup. But in case anyone of the readership wonders: restarts can also be invoked automatically by exception handlers. In case you don't want (or need) to leave the choice to the human with the cat on their laptop in some case. Thus restarts should be considered part of the interface of a solution, just like the exception types to be expected.
In a game I wrote 12 years ago I used restarts to put a request that arrived in an untimely manner (peer to peer communication between three parties) into a waiting queue of the messaging component to be redelivered later. That was in response to the exception of the game logic component that the request could not be processed by the state machine at this time.
Hi Lauren,
I am a big fan of Common Lisp conditions and restarts. Just as mentioned I too already mused on the list once that the debugger notifier buttons like Proceed and Abandon could be generalized in this way.
However, they are not Smalltalk "standard" (not even de facto), therefore not portable, and you must expect that they do not get widely adopted even in the Squeak community (how many of us use Traits?!). I could see them being used as a Squeak-internal feature though, like for the debugger buttons... And I would like to use them for some error recovery cases in the Git Browser if they were already there.
About increasing the complexity of the system, I am torn. In Cuis, restarts would probably have no place for that reason, unless the learning/understanding impact is really small. Maybe it would be good to see first how much more complicated things get with a restarts mechanism in place. But that may be well after you or anyone else has already invested most of the work.
So, I would be delighted to see this happen. But I also do not want to incite any illusions. ;-)
Kind regards, Jakob
Lauren P drurowin@gmail.com schrieb am Mo., 28. Nov. 2022, 17:49:
Hi List,
In reference to my question about the debugger in regards to Chronology-Core-dtl.80, I have a proposal.
I am halfway or so to stealing RESTART from Common Lisp for Squeak. It lets the programmer define alternatives for exception handling. Restarts would be responsible for making the Proceed, Abandon, etc. buttons in the debugger window, with every #on:offer: defining a button.
It's an extra layer of indirection and complexity in the evaluator, but it is an extremely powerful tool for writing clean code. If I had to choose one of an interactive debugger or restarts I'd pick restarts.
Implementation is easy but tedious... restarts have lots of optional parameters. If List thinks RESTART would be a good thing to have I will prioritize it.
PS: Whoever wrote the signalling code, thank you. It is very clean and easy to read. I learned everything about dynamic extent in Smalltalk from reading it.
-- Obviously, I vote yes, and the effort to not proselytize the Cult Of Restart here is great indeed.
Jakob,
On 11/28/22 18:05, Jakob Reschke wrote:
However, they are not Smalltalk "standard" (not even de facto), therefore not portable, and you must expect that they do not get widely adopted even in the Squeak community (how many of us use Traits?!). I could see them being used as a Squeak-internal feature though, like for the debugger buttons... And I would like to use them for some error recovery cases in the Git Browser if they were already there.
I wouldn't even care if it was unique to Squeak. I'm not really sure how much they get used in Common Lisp... I stayed away from them for a long time because I just never needed them, and, honestly, the example in the hyperspec lacks illustration. The normal HANDLER- macros were enough. Christoph's comment and my initial reaction to them are basically the same.
About increasing the complexity of the system, I am torn. In Cuis, restarts would probably have no place for that reason, unless the learning/understanding impact is really small. Maybe it would be good to see first how much more complicated things get with a restarts mechanism in place. But that may be well after you or anyone else has already invested most of the work.
Right? Hard to tell what the complexity will look like until after it's finished. And the ice cream sundae example... well... Sure, you'll learn, but you won't get.
So, I would be delighted to see this happen. But I also do not want to incite any illusions. ;-)
I mean, I'm half done. What's another half? ;3
squeak-dev@lists.squeakfoundation.org
-
Jakob Reschke -
Lauren P -
Lauren Pullen
-
Thiede, Christoph