Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126800 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 76A231A00BC for ; Mon, 17 Mar 2025 07:58:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1742198163; bh=/L5G9wmpRpEVnxF3/mZVq5qNzctXU9gp7NuRXXoB4Ac=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lBxXQ3zCCX00JMAxPmGj10lrPmKx5seB2Lmaf4i3xNcI4Vgdxv4yHB/bheiXiFmCq C+QKOWCy4tYcpycfpHBl3NhXvoInuN10rsbzt7oyoJdR4TSeVydd7AKE6CWHyGNpCR nYEYT9u18nH4VQc9IECC+O1UVcbENS1i4qnhfMU6yGUB/dz37Drs/m4pwMYv46ICh7 RBlO6ucvbqxOgOGStCHTuTwDjbPx3v+YDSOsZPGnrHM9SmPUVmkmoyH5fvDHt/jLga AQhLWWD4jFeqxJntyeFVqgFi8fAMiEJZPecj+jjdY3X1oUgYIno0utsnsm8GghgwLz AbZtiwJVTBKYA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 468B6180079 for ; Mon, 17 Mar 2025 07:56:02 +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=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MANY_SPAN_IN_TEXT,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-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 ; Mon, 17 Mar 2025 07:56:02 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e60b75f8723so2985939276.0 for ; Mon, 17 Mar 2025 00:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742198313; x=1742803113; 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=Wo8Jijo/obcl6j8SETpwQVYEeJwoGCdIj8d6HDe7owI=; b=lJ+EJFWM5yzIQ6Rqx8JevIJ+g4OrHUD7+XznmDzEEwhhl+yiUmlqgXxlvG/8EdTI1R Pb43/4lhEsDFAf+iK/M3GEXh7Sq7fDHOeJZ5G0SVb/4taTJ3YP51uxmpjwwbsTKOHKQC xAefovdsmGRdKdVoVm3bJzhlPesDAcZqWyPg1p/OZE/CVAkZ17K6AXtsROSvuzoBo7l+ 1n8obCgOrTBuPH8Yx4hy3BN5boytF+vY/ZUNdRF6W/gf3HOjeiHpxb4RH0Dr0doMaHeM AIOXoI17l6Qkrf9YYgNAanD5RR2x0h+JVkuvPbb5btg7Kds5GNwN8BvWle9Lq2LUzu8c u01g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742198313; x=1742803113; 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=Wo8Jijo/obcl6j8SETpwQVYEeJwoGCdIj8d6HDe7owI=; b=gwG3BsFXAbVWvsPgPNJgZDVqfxt5IbJx678VJ7yqaSIyCRrIKH4f5cN1e0HtsCD11W mBghQDMTY35eOKSWrJPfEPQwzCNjX6BKEwJrBfYEMpDdRohmrGN6FwV1HJxcaIm7hsJC cl9dx0BT2BV7csQ2cjLCh0ZvaO5Wa3zmbEX5JOUlvs9N2xUAw1UuDYudHZbzjX8rEsYT b+aOC4oyGsyZ34pZFLwSLcApMNUOSAUyGVUwHRxl1VSYXuk0aN5xZkTpus2pCtwi1Cie eZYu29T21o2V4KHkHz9VG42zuXr69Pd9aBvr3b+hbfbfPkLfDzCRKwfCdKfcahqeWVIT mfLw== X-Gm-Message-State: AOJu0YyWNFukXKWP/gx55xeLIywVqkXu71r5lJcLDoKU8bmlNrGNhmwQ 0hFaGxe3Pntl8yC6uTVGxpg+SQZfkIE2VTOv4fJ7L9lsxO1/2nq6RkJ0IiQE4QOmCAGZLhp2C8j ALvAqrrfIHyDHgNGOhG6aGOzV0sT9XUd79Cg= X-Gm-Gg: ASbGnctxe+Y4/Yvsvp4g0jnRkazcMNtefUHPT1TMWt3ZHYiIm1rZozrWKsWDB6aA6ps Eg4zXvRyUrIx5M6IhdRSPzHQsooayo7s+OB15s2DadN8WC+6ClA/mprcKStL1bnX/m1FH6YQQf6 JAluSmjHZrw1fZ4SZ+j2ABi6xSuA== X-Google-Smtp-Source: AGHT+IF8ixqHEaTODPwnVcylgTj52FbOVkjA2iTb1QSkOp0kH8jBuZHMniNQx69iQBcKp7n5wt5xQhmz6fkrF9LaIag= X-Received: by 2002:a05:6902:2702:b0:e5b:32f5:e38b with SMTP id 3f1490d57ef6-e63f652ca16mr13845743276.23.1742198313206; Mon, 17 Mar 2025 00:58:33 -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> In-Reply-To: <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk> Date: Mon, 17 Mar 2025 09:58:22 +0200 X-Gm-Features: AQ5f1JofFl5PufAtTsZ-zVqh9QEW-YfsyPMA3fdE1HMtG6tvb2dlhI59DlNG_v8 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="000000000000964ef0063085278c" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000964ef0063085278c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. In this email, I will focus only on the syntax because it is a separate and rather complex topic. First, the RFC does not clearly describe the syntax, which needs to be fixed. Second, you are right that methods and operators cause confusion. However, I really liked the `$scope->spawn()` construct in the example code, as it feels the most natural compared to `spawn in`. Moreover, the `spawn in` expression is quite complex to implement, but I don't have enough experience to evaluate it properly. ## Defer I have nothing against the `suspend` keyword. However, the `defer` keyword raises some questions. "Defer" means to postpone something (to delay execution). But in this case, it=E2=80=99s not about "postponing" but rather "executing= upon function block exit." I don't know why the creators of Go chose this word. I considered `finally`, but it is already used in the `try` block. The implementation also concerns me a bit. It seems that to fully implement the `defer` block, we would need something similar to `finally`, or essentially make `defer` create an implicit `try...finally` block. ## Spawn Operator Yes, the chosen syntax has some ambiguity because there are two versions. However, I didn't like the other options, mainly due to their verbosity. **General syntax:** ```php spawn [in ] function [use()][: ] { }; ``` where: - `parameters` - a list of parameters passed to the closure. - `returnType` - the return type of the closure. - `codeBlock` - the body of the closure. Examples: ```php spawn function { echo "Hello"; }; spawn function:string|bool { return file_get_contents('file.txt'); }; // Incorrect syntax spawn { echo "Test\n"; }; ``` ##### In scope expression The `in` keyword allows specifying the scope in which the coroutine. ```php $scope =3D new Async\Scope(); $coroutine =3D spawn in $scope function:string { return "Hello, World!"; }; function test(): string { return "Hello, World!"; } spawn in $scope test(); ``` The `scope` expression can be: - A variable ```php spawn in $scope function:void { echo "Hello, World!"; }; ``` - The result of a method or function call ```php spawn in $this->scope $this->method(); spawn in $this->getScope() $this->method(); ``` The form `spawn ();` is a shorthand for `spawn use(, ) { return ... };` The expression `();` is not executed directly at the point where `spawn` is used but in a different context. There is a slight logical ambiguity in this form, but it does not seem to cause any issues with comprehension. As for the form: `spawn ()(parameters)` =E2=80=94 I suggest not implementing it = at all. It makes the code unreadable, and carries no meaningful advantage. Saving a single variable only to get lost in parentheses? It's not worth it= . :) ### Spawn Form The form `spawn ();` is a shorthand for: ```php spawn use(, ) { return ... }; ``` The expression `();` is not executed directly at the point where `spawn` is used but in a different context. There is a slight logical ambiguity in this form, but it does not seem to cause any issues with comprehension. As for the form: ```php spawn ()(parameters); ``` I suggest not implementing it at all. It is simply terrible, makes the code unreadable, and carries no meaningful advantage. Saving a single variable only to get lost in parentheses? It's not worth it= . :) ### Why do I use the `function` keyword in the second form? Only to allow defining the return type. In principle, both forms are equivalent: ```php spawn {}; spawn function {}; ``` I also like the `function` keyword because it unambiguously indicates that this is not just a block of code but specifically a closure. What I don=E2=80=99t like: This form might complicate semantic analysis since now there are two types of closures to parse. Intuitively, it would be good to define it like this: ```php spawn function() use() {}; ``` =E2=80=94 meaning to literally mirror the standard closure definition. This way, an existing analysis block could be reused. But what should we do with parameters? :) In other words, I would prefer this aspect to be reviewed by someone who is equally well-versed in the implementation. --- Ed. --000000000000964ef0063085278c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

In this email, I will= focus only on the syntax because it is a separate and rather complex topic= .

First, the RFC does not clearly describe the syntax, which needs t= o be fixed. =C2=A0
Second, you are right that methods and operators caus= e confusion. =C2=A0
However, I really liked the `$scope->spawn()` con= struct in the example code, as it feels the most natural compared to `spawn= in`. =C2=A0
Moreover, the `spawn in` expression is quite complex to imp= lement, but I don't have enough experience to evaluate it properly.
=
## Defer

I have nothing against the `suspend` keyword. =C2=A0However, the `defer` keyword raises some questions. "Defer" mean= s to postpone something (to delay execution). =C2=A0
But in this case, i= t=E2=80=99s not about "postponing" but rather "executing upo= n function block exit." =C2=A0
I don't know why the creators of= Go chose this word. I considered `finally`, but it is already used in the = `try` block. =C2=A0

The implementation also concerns me a bit. =C2= =A0
It seems that to fully implement the `defer` block, we would need so= mething similar to `finally`, or essentially make `defer` create an implici= t `try...finally` block.

## Spawn Operator

Yes, the chosen sy= ntax has some ambiguity because there are two versions. =C2=A0
However, = I didn't like the other options, mainly due to their verbosity.

**General syntax:**

```php
spaw=
n [in <sco=
pe>] function [use(<parameters<=
span style=3D"color:rgb(6,125,23)">>)][: <returnType>] {
    <=
;codeBlock>
};
```

where:

- `parameters` - a list of parameters passed to the closure.
- `returnType` - the return type of the closure.
- `codeBlock` - the body of the closure.

Examples:

```php
spawn function {
    echo "Hello";
};

sp=
awn function:string|=
bool {
    return =
file_get_contents('file.txt');
};

<=
/span>// Incorrect syntax
spawn {
=
    echo "Test\n";
=
};
```

###=
## In scope expression

The `in` keyword allows spe=
cifying the scope in which the coroutine.

```php
$scope =3D new Async\Scope();

$coroutine =3D spawn in =
$scope function:string {
    return "Hello, World!";
};=


function test(): string {
    return "Hello, World!&q=
uot;;
}

spawn in $scope test();
```

The `scope` expr=
ession can be:
- A variable
```php
spawn in $scope function:void=
 {
    echo "Hello, World!";
};
```

- The result of a method or function call

```php
spawn in $this->scope $this=
->method();
spawn in $this->getScope() $thi=
s->method();
```
The form `spawn <callable&=
gt;(<parameters>);` =C2=A0
is a shorthand for `spawn use(<calla=
ble>, <parameters>) { return ... };` =C2=A0
The expression `<=
;callable>(<parameters>);` is not executed directly at the point w=
here `spawn` is used but in a different context.

There is a slight l=
ogical ambiguity in this form, but it does not seem to cause any issues wit=
h comprehension.

As for the form: =C2=A0

`spawn (<expression>=
;)(parameters)` =E2=80=94 I suggest not implementing it at all. =C2=A0
<=
br>
It=
 makes the code unreadable, and carries no meaningful advantage. =C2=A0
=
Saving a single variable only to get lost in parentheses? It's not wort=
h it. :)
### Spawn Form

The form `spawn <callable>(<parameters>);`  
is a shorthand for:

=
```php
spawn use(=
<callable>, <parameters>) { retu=
rn ... };
```

The expression `<callable>(<parameters>);` is not executed directly at the point whe=
re `spawn` is used but in a different context.

There is a=
 slight logical ambiguity in this form, but it does not seem to cause any i=
ssues with comprehension.

As for the form:

```php
spawn (<expression>)(pa=
rameters);
```
=

I suggest not implementing it at all.  
It is simply terrible=
, makes the code unreadable, and carries no meaningful advantage.  
Savi=
ng a single variable only to get lost in parentheses? It's not worth it=
. :)

### Why do I use the `function` keyword in the second form?  

Only to allow defining the retur=
n type.  

In principle, both forms are equivalent:  

```php
spawn {};
spawn function {};
```

I also like the `function` keyword because it unambiguously in=
dicates that this is not just a block of code but specifically a closure.
What I don=E2=80=99t like:
This form might complicate semantic ana=
lysis since now there are two types of closures to parse.  
Intuitively,=
 it would be good to define it like this:

```php
spaw=
n function() use() {};
```

=E2=80=94 meaning to literally mirror the standard c=
losure definition.  
This way, an existing analysis block could be reuse=
d.

But what should we do with parameters? :)
In other words, I would p=
refer this aspect to be reviewed by someone who is equally well-versed in t=
he implementation.
---
Ed.
--000000000000964ef0063085278c--