<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 February 2018 at 07:12, Tony Garnock-Jones <span dir="ltr"><<a href="mailto:tonyg@leastfixedpoint.com" target="_blank">tonyg@leastfixedpoint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot,<br>
<br>
On 02/15/2018 07:34 PM, Eliot Miranda wrote:<br>
> One thing to think about is that, because exception handling in<br>
> Smalltalk is above the VM, exception handling does not have to be<br>
> limited to a stack-oriented propagation.  There is no reason why<br>
> promises could not keep track of their creating environments and that<br>
> exception propagation could be modified to cross promise boundaries,<br>
> searching for handlers within their originating contexts.<br>
<br>
Yes, that's a neat idea. I've been mulling over something similar,<br>
regarding callbacks attached to Promises. Sometimes it's OK to run them<br>
in the context of the UI process, but other times they really want to be<br>
run in the context of the process that was running at the time they were<br>
attached to the Promise. I'm still thinking about what the smallest<br>
change I can get away with might be.<br>
<br>
In general, exceptions per se - or rather, stack-based exception<br>
*handler* mechanisms - don't adapt well to a concurrent setting. Miller,<br>
Tribble and Shapiro's "Concurrency Among Strangers" (2005) [1] is great<br>
on this topic. Their idea of "plan interference" really captures the<br>
problem well.<br>
<br>
  [1] <a href="http://www.erights.org/talks/promises/paper/tgc05.pdf" rel="noreferrer" target="_blank">http://www.erights.org/talks/<wbr>promises/paper/tgc05.pdf</a><br>
<br>
However, aside from the E-style techniques, an Erlang style design works<br>
quite well. There, stack-oriented exceptions and exception handlers cope<br>
with error signalling and recovery within a process, and Erlang's "link"<br>
mechanism propagates entire actor failures among processes. (In some<br>
ways this is reminiscent of E's two-layered design, with vats containing<br>
objects.)<br>
<br>
> Perhaps this is what the onRejected: mechanism does.  But I've wondered<br>
> for a few years (without playing, and so my thoughts are vapor and<br>
> probably quite ill-formed) that such a system could be more convenient.<br>
<br>
Yep. My recently-completed doctoral work was on a new actor/tuplespace<br>
inspired hybrid model of concurrency that in some ways makes things like<br>
error signalling and recovery less terrible. (See<br>
<a href="http://syndicate-lang.org/tonyg-dissertation/" rel="noreferrer" target="_blank">http://syndicate-lang.org/<wbr>tonyg-dissertation/</a> if you're interested.)<br></blockquote><div><br></div><div>Congratulations!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> might be possible to have promises hold onto their originating<br>
> environments so that when an uncaught exception does occur in a promise<br>
> one can make sense of its history.<br>
<br>
Recording this kind of causal information is hard, but could be<br>
worthwhile. I don't yet have enough experience with Promises to be able<br>
to do the design work. I wonder if there's an overlap with "E-order".<br>
I've always had trouble digging through <a href="http://erights.org" rel="noreferrer" target="_blank">erights.org</a> enough to get a<br>
clear picture on exactly what E-order entails.<br></blockquote><div><br></div><div>C# Tasks (promises) routinely keep track of their "stack", for what it's worth. I've never had a need to look into how exactly they do this, but maybe that's an avenue to explore?</div><div><br></div><div>Debugging Task-based code never feels any different to debugging "normal" code, FWIW. (Of course that may well be because I make sure my colleagues use immutable data structures and all that...)</div><div><br></div><div>frank</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
  Tony<br>
<br>
</blockquote></div><br></div></div>