Hacker News Reader

Comment by foobar_ | Hacker News Reader

`UNWIND-PROTECT` thats cool!

What I meant with the promises was, If you could pass three closures ... like success, error, restart could you get some kinda condition system ?

View on HN

That's not enough. The condition system decouples the act of signaling a condition from the act of deciding how to handle it. This means that the promise would need to reach out to its dynamic environment to figure out what it would need to do in case of errors and restarts.

And that also only handles the case of "help I'm ded get me out of here". What about signals that do not expect to be handled, and instead are used to transfer information higher up the stack by invoking a handler function specified in the dynamic environment? That's a valid use of the condition system, as outlined in the book.

It's notable that the Worlogog::Incident and Worlogog::Restart perl modules on CPAN provide a condition system whose unwinding is implemented by Return::MultiLevel which contains a fallback pure perl implementation that does use goto-to-outer-function's-label (with gensym-ed label names for uniqueness).

Works for perl because while we don't (yet, somebody's working on one) have an unwind-protect like primitive, perl's refcounting system provides timely destruction so you can use a scope guard object stuffed into a lexical on the stack whose DESTROY method does whatever unwind cleanup you need.

Ironically, the main reason I'm not using this so much at the moment is that it isn't compatible with the suspend/resume code around promises provided by Future::AsyncAwait and I'm heavily using that in my current code, but at the point where I need both I'll probably attempt to nerd snipe one of the relevant authors into helping me figure it out.

(EDIT: Aaaaactually, I think I might already know how to make them work together, naturally an idea popped into my head just after I hit the post button ... using Syntax::Keyword::Dynamically and capturing a relevant future higher up the chain of calls should allow me to return-to-there cleanly, then I "just" need to cancel the intermediate futures to simulate unwinding ... but I'll have to try it to find out)

Yes. Destructors are an equivalent of UNWIND-PROTECT, just like Java's finally{...} block of the try/catch/finally trio.

Thank you for mentioning Worlogog, I'll include that in the book. How should I credit you?

Not quite an equivalent in perl because there are limitations like exceptions being discarded if you're unwinding because of an exception being thrown, but it's entirely possible to make things go if you know what you're doing ;)

"Matt S. Trout (mst)" is good - I'm probably better known by my IRC nick than my full name in geek circles ;)

I'll keep that in mind, and I'll add that link to the book's contents, and I'll add you to my book's Hall of Fame. Thanks.

The author of Future::AsyncAwait is working on a patch to core to provide LEAVE {} blocks which will be a more full unwind-protect solution. Note of course the destructor limitation doesn't affect Worlogog use so much since you're -not- throwing exceptions, but once you're into mixed condition and exception based code of course things that to get more "fun".

> once you're into mixed condition and exception based code of course things that to get more "fun".

I imagine that is the reality of everyone who tries to implement a condition system in a language where the default behavior is to immediately unwind the stack by throwing some sort of an exception.

Yes. But as the only perler I've seen in this thread I wanted to do my best to be honest about the risks.

If I were to want to continue discussing this, do you happen to kick around anywhere on IRC that would be suitable?

#lisp on Freenode sounds okay - my nickname is phoe.

Reply on news.ycombinator.com