On 07/03/2025 22:01, Larry Garfield wrote:
Is that what you're suggesting?  If so, I'd have to think it through a bit more to see 
what guarantees that does[n't] provide.  It might work.  (I deliberately used spawn 
instead of "await" to avoid the mental association with JS async/await.)  My 
biggest issue is that this is starting to feel like colored functions, even if partially 
transparent.


Yes, that's pretty much what was in my head. I freely admit I haven't thought through the implications either.


My biggest issue is that this is starting to feel like colored functions, even 
if partially transparent.


I think it's significantly *less* like coloured functions than passing around a nursery object. You could almost take this:

async function foo($bar int, $baz string) {
    spawn something_else();
}
spawn foo(42, 'hello');

As sugar for this:

function foo($bar int, $baz string, AsyncNursery $__nursery) {
    $__nursery->spawn( something_else(...) );
}
$__nursery->spawn( fn($n) => foo(42, 'hello', $n) );

However you spell it, you've had to change the function's *signature* in order to use async facilities in its *body*.


If the body can say "get current nursery", it can be called even if its *immediate* caller has no knowledge of async code, as long as we have some reasonable definition of "current".


--
Rowan Tommins
[IMSoP]

Reply via email to