Paul Cantrell
Hot take from me that I’m not sure even I agree with:
In an async function, asynchrony should be the default expectation — no explicit `await`! suspension point could occur anywhere! — but non-local state mutations must occur inside state change transaction blocks (something like `atomic { … }`) inside of which async calls are illegal.
Paul Cantrell
@cocoaphony
Meaning local vars are OK. I guess? I haven’t thought this through at all.
Rob Napier
@inthehands How is "non-local state mutation" statically defined in this story?
Paul Cantrell
@aubilenon
I just mean in a language that •already• has async / await, using whatever scheme it uses, what if there were a change in the syntactic markers?
Jesse Morris
@inthehands What would cause one async task, with lots it can do without waiting, to get suspended for some other async task? How would this be implemented efficiently?
Daniel Leigh
@inthehands That's essentially just preemptive multitasking with enforced mutexes, isn't it?
Paul Cantrell
@danielleigh
It does feel similar, but (1) async/await usually uses some kind of coop multitasking / event loop / coroutine implementation strategy, which has very different guys & performance characteristics, and (2) such languages usually have some kind of global lock or data isolation domains or some other way of deciding which pieces of code can run simultaneously that is structured very different from a mutex.
Rob Napier
@inthehands think about whether logging is “mutable state.” (Then think about it again remembering that OSLogStore is readable.) That’s probably the best way to come to grips with the difficulty we always run into with defining “pure.”
Is generating random number legal in an async function if it modifies the RNG state? State is so pervasive.
Paul Cantrell
@cocoaphony
Yes yes yes, and in 2 minutes we’ll be talking about IO monads, but I’m not trying to get as grandiose as complete static enforcement of state updates. I’m just suggesting that in most any language that has some form of async/await, thinking about state updates transactionally is already a best practice, and maybe the syntax should tilt in that direciton.
Paul Cantrell
@cocoaphony
I am proposing zero semantic changes.
Rob Napier
@inthehands and I think when you go down that path a little further you work yourself into the current await semantics to achieve exactly that.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.