<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Aug 17, 2017, at 10:50 PM, Andre <<a href="mailto:pyunpyun@me.com" class="">pyunpyun@me.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><h2 style="box-sizing: border-box; margin-top: 24px; margin-bottom: 16px; line-height: 1.25; padding-bottom: 0.3em; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(234, 236, 239); color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; background-color: rgb(255, 255, 255); font-size: 16px;" class="">Part 1: Async/await</h2><div style="" class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; margin-top: 0px; margin-bottom: 0px; font-stretch: normal; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""> <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">let</span> dataResource <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">=</span> await <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">loadWebResource</span>(<span class="pl-s" style="box-sizing: border-box; color: rgb(3, 47, 98);"><span class="pl-pds" style="box-sizing: border-box;">"</span>dataprofile.txt<span class="pl-pds" style="box-sizing: border-box;">"</span></span>)<span style="" class="">
</span></pre></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Was there any thought about introducing the concept of a <i class="">timeout when awaiting</i>?</div><div class=""><br class=""></div><div class="">Something like an `await for:` optional parameter?</div><div class="">Then, if used with try, it could go like…</div><div class=""><br class=""></div><div class=""><font face="Menlo" size="1" class=""> <font color="#d73a49" class="">let</font> dataResource = <font color="#d73a49" class="">try</font> await <b class="">for:<font color="#005cc5" class="">10</font><font color="#a2abab" class="">/*seconds*/</font></b> <font color="#005cc5" class="">loadWebResource</font>("dataprofile.txt”) <span style="color: rgb(215, 58, 73);" class="">catch </span>_<span style="color: rgb(0, 92, 197);" class=""> </span><font color="#d73a49" class="">as</font><span style="color: rgb(0, 92, 197);" class=""> </span>Timeout { //abort,retry cancel } </font></div><div class=""><br class=""></div><div class="">Timeouts should probably be handled at a higher level, but its just something that jumped out to me a little, since its something I notice sometimes people neglect to take care of… :/</div></div></div></div></blockquote><div><br class=""></div><div>Something like this could definitely be built and added later: the sketch for async/await is intentionally kept as minimal as possible. That said, this seems like it is wandering into territory that would make sense to be API, rather than first class language feature.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><span style="color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; background-color: rgb(255, 255, 255);" class="">Part 2: Actors</span></div><div class="">One other thing that also jumped at me was, if we are going to have actors, and having them encapsulate/isolate state, would it also make sense to make sure that we can’t invoke state changing messages when its invalid?</div><div class=""><br class=""></div><div class="">As an example, if we had a ”downloader” actor that downloads multiple files, we wouldn't want to be able to send invalid messages such as `begin` when downloading has already ”begun”…. Would it then make more sense to have callable messages be determined by the publicly visible state of the actor instead?</div></div></div></blockquote><div><br class=""></div><div>Yes, I completely agree and know what you’re talking about here. You’re unintentionally poking one of my other axes the grind. :)</div><div><br class=""></div><div>This desire (to have conceptual “states” that a type moves through) is something that is super common. Files can be in “initialized” and “open” states, and that changes the valid actions that can be performed on them. A mutex can be locked or unlocked etc. Being able to express these invariants is highly related to pre and post conditions.</div><div><br class=""></div><div>One abstraction that has been developed in the industry is the notion of typestate (<a href="https://en.wikipedia.org/wiki/Typestate_analysis" class="">https://en.wikipedia.org/wiki/Typestate_analysis</a>), which underlies common abstractions in static analyzer tools like the Clang Static Analyzer. I would love to see these ideas developed and built out at some point in time, and perhaps the next time I get a long block of time I’ll write another manifesto on those ideas ;-)</div><div><br class=""></div><div>Coming back to your point, these ideas apply just as much to structs and classes as they do actors, so I think it should be a feature orthogonal to actors.</div><div><br class=""></div><div>-Chris</div></div></body></html>