On 19 March 2025 15:51:38 GMT, Edmond Dantes <edmond...@gmail.com> 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]
