Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126859 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 71FDD1A00BC for ; Thu, 20 Mar 2025 11:01:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1742468352; bh=t71PlKIYoSLUdD3rA4Q7c4Ve/BMMMUI6NPZwu7G/X0o=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YCSfItRLPxkAJbvrEAI2GpuK+ZEhz6mEdbtzznsaApAUON6Xx7E+FB2KLxfGbR8+l zFgaFixBLOX2Tq4UDN7Tm/GCQ2iDKVT//usX1PvMyPf1gYX0S9o2wVSDGzbipLhmx/ /kd/BqepicjdQjs6QuiS9zY2uC4AYPEntuHFZzx6lL0eiPg0VURAmm82CsnFdyES3s lFYvJTkeCqyLaQYnMz4FSTZzqaiy+jXGDIgVAAJHBhkYWqRgWCkMnB69YlZLtDXHey UhLaVbYKYhVERWL8W6HoJW8mOnj74ivwkFWVlVR6+/UW6oGbhxqDT4wKTvkQl9x7Mj pr6docB85ULtA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 686A9180050 for ; Thu, 20 Mar 2025 10:59:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 20 Mar 2025 10:59:11 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-e643f234e08so430778276.0 for ; Thu, 20 Mar 2025 04:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742468501; x=1743073301; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=88A8y/NNNkevuTqk8kQENg25wRj6S2Y+7wTUMPvAcxc=; b=gz4Uql8LM9ZnXib3n6cKBFwcRJMg2dQPRL2KAAWh9jYhWF6kgqm2/qj9I/v7TCgzgE rTxDAFmsm0R6ikmZPn+ruLC0IOIyX+EVmo2kk69UrHL9x8IAiFq71GaIqsgOnEXkNbcT G+FuNSeBjbI86j/uTQyi97c77yz3IvWrN6KqHFBoBZk9CUt4nBmw3ddRX4WoaGSeaS5I kz0mJ0cAuN/z+IfJqi6TzlyiCW3/Sq4COLJlETrFUbnDQY9ydLp9zZpHYJMjaD6uCAMM yY6/TJ1OR80Pcnhl4mk7VMOiic5r/8wirLS6gFXZCKVELmxVfhFl0cwX2IoTgi3akzAw AckA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742468501; x=1743073301; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=88A8y/NNNkevuTqk8kQENg25wRj6S2Y+7wTUMPvAcxc=; b=XANvPACbjNC+vCxvM+wVxj8u25cs4r/nf5N7gJ6wYadRdHCGZFy8S1NVGEtMmgO4Dm 0Wwnr13VVdh+4GeBLoFJOrJJZ8s24feaiiNIRHU40omlT6itc4SEYMJaXX8Y02JLqbxj vfvk3kcqF+6PvmDV1S/fZKT26p1QOYMQ84Yj+xHEy/iX1tDI11GUa5sBjOcF2BjHVVmp gc/YNYsoyD+i/PhkcKoRQvM7NLXyiywqpD3WehaZjHhDiSDDCMJOvMBcw7sPtEX8rv3k Yochl9zZBe47450PCaV/59VptDCimfp4Rik17plnMNm1JDb8k8e8cRsSj7/YQeB6H0+6 5KJg== X-Gm-Message-State: AOJu0YxBBi88tq6DWsoRZvy75zs1vRk7GVcpdbAZfVFFAx9fEWnkjPcQ p+aiWbVcdFXV6JXnqFlmnvMkddhDQ4JxXsdahwJaD02MF3fBq0/tnEBYaoQpEBetkmTUNJDqDv0 9K7dyRl+97UliBisD9WX1T+b/UlKUaOs6V0k= X-Gm-Gg: ASbGncvIfhhrHZmqWufvpd6VhwD5OSp95noY7ozUuP9pSfxQWUrOJRXzXc1QKGKEQQX 3vk56T3wQf6240bnmb8Gi2n5o28ANKHnj38C9AwABt0Y7VraEZZw0rDekyQmTCgL+dDZCBE0GXr eib+JzMPxdUBJT5UjAibYEL+1FxQ== X-Google-Smtp-Source: AGHT+IEkBkvlJ7ahJGoMQedZumgB7U/IR3St3r43edgZT1MM77n6G++DHBhzS4NsYUVmG0yqbrBzrVOn9Z0oeed1yv4= X-Received: by 2002:a05:6902:2786:b0:e63:efca:6692 with SMTP id 3f1490d57ef6-e667b3b326amr7657103276.6.1742468501227; Thu, 20 Mar 2025 04:01:41 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk> <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk> <2F013672-9937-4AB1-BC46-86F3D342BE6B@rwec.co.uk> <743c84d4-28db-4f68-80e5-3cad2dac6e68@rwec.co.uk> In-Reply-To: Date: Thu, 20 Mar 2025 13:01:30 +0200 X-Gm-Features: AQ5f1Jq-Jt-34-A-j9h4YXKJGcjhvvKoNjqoFZbX4ME-XaiRoAqcEEI3_kEP7hg Message-ID: Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2 To: "Rowan Tommins [IMSoP]" Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000000c54ad0630c410c2" From: edmond.ht@gmail.com (Edmond Dantes) --0000000000000c54ad0630c410c2 Content-Type: text/plain; charset="UTF-8" > In terms of the grammar, it is a special case of #1 yes. > This example maybe helps explain why this might be surprising: > spawn $action; Aha, so if I can write `spawn closure`, why can't I do the same with a variable? Yes, this creates an inconsistency. that's to be expected since the parentheses were removed. > > This feels like a stretch to me > From the perspective of how responsibility is distributed in the code, this would be correct. But it has nothing to do with syntax consistency. > > From the user's point of view, it might be just as obvious that the closure put into a variable two lines above can also be called with zero arguments. > It's only as unclear as any other code involving a variable - if it's badly named and defined 100 lines away, > you'll have a problem, but no syntax can solve that. > That's correct. But I'm not sure it's that destructive in practice. > > I tried to make clear that the keywords could stand in for anything Yes, you want to keep the concise syntax while eliminating ambiguity with the variable. > > Specifically, what is the use case where syntax #2, "spawn function_call" is not good enough, leading us to add a special case into the grammar. > Additional parentheses around + parentheses after. That is, (closure)(). The goal is to get rid of this construct. > > Will it? By who, when? Honest question, and comes back to my point about identifying the use case. > Honest answer: I can't say for sure. I can assume that closures help define a small sub-area within a piece of code that performs a specific task. How common is this situation in the context of coroutines? Maybe not that much. A safer approach would be to implement only syntax 2 and consider the alternative option only if user feedback suggests it's needed. Sounds like a solution without drawbacks... > If return values end up somewhere, I don't think it would be hard to come up with examples that were slightly more than one function call, but still fit in a single-expression closure. like: ```php spawn fn() => [file_get_content(), file_get_content(), file_get_content()] ``` At this point, I haven't been able to come up with examples where such a closure would actually be convenient. Maybe this use case will emerge later. --0000000000000c54ad0630c410c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 In terms of the grammar, it is a special case of #1
yes.

=
> This example maybe helps explain why this might be surprisi= ng:
> spawn $action;

Aha, so if I can write = `spawn closure`, why can't I do the same with a variable? =C2=A0
Yes= , this creates an inconsistency.
that's to be expected since the par= entheses were removed.=C2=A0=C2=A0

>
>= ;=C2=A0 This feels like a stretch to me
>
From the perspective of h= ow responsibility is distributed in the code, this would be correct.=C2=A0= =C2=A0
But it has nothing to do with syntax consistency.=C2=A0=C2= =A0

>
>=C2=A0 From the us= er's point of view, it might be just as obvious that the closure put in= to a variable two lines above can also be called with zero arguments.
&g= t; It's only as unclear as any other code involving a variable - if it&= #39;s badly named and defined 100 lines away,
> you'll have a pro= blem, but no syntax can solve that.
>

That&#= 39;s correct.=C2=A0 But I'm not sure it's that destructive in pract= ice.=C2=A0=C2=A0

>=C2=A0
>=C2=A0I tried to make clear th= at the keywords could stand in for anything

Yes, you want= to keep the concise syntax while eliminating ambiguity with the variable.= =C2=A0=C2=A0

>
>=C2=A0Specifically, what is the use case where syntax #2, &q= uot;spawn function_call" is not=C2=A0good enough, leading us to add a special case i= nto the grammar.Will it? By who, when? Honest quest= ion, and comes back to my point about identifying the=C2=A0use case.
>

Honest answer: I can't say for sure.

I can assume that closures help define a small sub-area within a piece o= f code that performs a specific task. How common is this situation in the c= ontext of coroutines? Maybe not that much.

A safer approach would be to implement only syntax 2 and consider the al= ternative option only if user feedback suggests it's needed. Sounds lik= e a solution without drawbacks...=C2=A0=C2=A0

> If return values end = up somewhere, I=C2=A0 don't think it would be hard to come up with exam= ples that were slightly more than one function call, but still fit in a sin= gle-expression closure.

like:
```php
spawn fn() =3D> [file_get_cont= ent(),=C2=A0file_get_content(),= =C2=A0file_get_content()]
```

At this point, I haven't been able to come up with examples where= such a closure would actually be convenient. =C2=A0
Maybe this use case= will emerge later.=C2=A0
--0000000000000c54ad0630c410c2--