On 19 March 2025 15:51:38 GMT, Edmond Dantes <[email protected]> wrote:
>>
>> "Cheating" in the sense that you wrote out a "general syntax",
>>
>I got it.
>
>> That's not the problem; the problem is that the following are all
>equivalent expressions:
>> (((foo())))
>
>In principle, this is not a problem because the expression in parentheses
>preceded by spawn is unambiguously a call expression.
>That is, from an analysis perspective, everything is fine here because the
>expression spawn () is a syntax error.
This has nothing to do with my examples.
If you start with a valid expression, you can add any number of parentheses around it, and get
another valid expression, with the same meaning. A function call is an expression, and a function
call wrapped in parentheses is another way of writing the same expression.
But even though we're talking in circles about why, your latest examples do avoid the
particular problem I was trying to describe.
>From the user's perspective, what is the difference between these two
>expressions?
>
>```php
>spawn function(): string { ... };
>spawn (function(): string { ... });
>```
Yes, that would probably be a bad choice as well. Which is why I've repeatedly suggested a
different keyword, and AFAIK you still haven't actually voiced an opinion on that.
>If we define the rule spawn function_call, then spawn acts as a prefix
>in this expression. However, everything that is already defined for
>function_call in PHP must remain valid.
Yep, I'm totally fine with that. But you kept referring to that token as
"expression", which confused me, because that's a different thing in the grammar.
>The second form of the spawn expression is:
>```php
>spawn inline_function
>```
This part totally makes sense from a syntax point of view, I just think it has bad usability - the
user has to type a bunch more boilerplate, which looks like something it's not.
>> If it's going to be a special case for an "inline coroutine", just use a
>keyword other than "function", so it doesn't look like an expression when
>it's not, like "spawn block { ... }"; or no keyword at all, just "spawn {
>... }"
>>
>
>Well, yes, but here we again face the issue with returnType syntax, which
>ends up hanging in the air...
I think I asked this before: why would anyone want to specify a return type there?
I assumed the actual user scenario we're trying to solve is "I have a bunch of statements
I want to run in a new Coroutine, but they're not worth putting in a function". So to the
user, having all the features of a function isn't relevant. We don't allow specifying the
return type of a match statement, for example.
Do you have a different scenario in mind?
Rowan Tommins
[IMSoP]