
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="">On Feb 6, 2020, at 02:28, Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div class="gmail_quote"><div class="">The issue here is that raiseAsync is destructive - it *moves* the stack to the heap, rather than copying it. So if you want to continue execution where you left off, for shift#, you would have to copy it back onto the stack again. That's the point I was trying to highlight here.</div></div></div></div></blockquote><div class=""><br class=""></div>Ah, yes, I see what you mean! It happens that for my use case I actually do want to unwind the stack when I capture a continuation, so that isn’t a problem for me.<br class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"></div></div></div><div><br class=""><blockquote type="cite" class=""><div class="">Yes, these are all the things that make raiseAsync tricky! You can either copy what raiseAsync does (but be warned, it has taken a lot of iteration to get right) or try to use raiseAsync and/or modify it to do what you want.</div></blockquote></div><br class=""><div class="">My point was more that I’m unsure that shift# <i class="">should</i> handle most of those cases. For raiseAsync, it makes sense, since asynchronous interrupts can, by their nature, occur at any time, even during pure code. But my shift# operation lives in IO, and the intent is to only capture up to a reset# in the same state thread.</div><div class=""><br class=""></div><div class="">My justification for this is that if you could use shift# in pure code, it would be ill-defined what you’d even be capturing. Suppose you return a thunk containing a call to shift#. When the thunk is evaluated, you capture up to the nearest reset#… but who knows what that is now? This opens you up to all sorts of general badness.</div><div class=""><br class=""></div><div class="">Therefore, I don’t think there should ever be an UPDATE_FRAME in the captured continuation—if there is, it’s probably a bug. So unless someone can think of any valid use cases, I’ll make that more explicit by modifying the continuation-capturing code to add some assertions that those frames never appear in the captured stack.</div></body></html>