Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109606
To: PHP internals <internals@lists.php.net>
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
 <C3F55856-66AF-44F5-8F43-8E41FA8DC6E8@gmail.com>
 <CAPyj-LBt_Cq+qa49+H3Tav+uepSJ23+TPg_JN5DofGC7y8fnoQ@mail.gmail.com>
 <6aebe21d-2137-885e-5ee9-99d4f917a7f9@gmail.com>
 <CAPyj-LAo0tnG=tMJ_ir9SoaYKa1WM1AYCAiyfQ8Xkkx=W4usEw@mail.gmail.com>
 <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com>
 <CAPyj-LD87_6VcUNLtJbqQatUpBO1fTDb1f_ZgLyAp2fSjqYaLA@mail.gmail.com>
Message-ID: <e801f32f-7f74-4d3e-4494-5242f213f101@gmail.com>
Date: Mon, 13 Apr 2020 15:49:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAPyj-LD87_6VcUNLtJbqQatUpBO1fTDb1f_ZgLyAp2fSjqYaLA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 13/04/2020 12:28, Ilija Tovilo wrote:
>> It would be possible for the blocks to return values (though not with
>> the return keyword).
>> [...]
> We can't do everything at once.


Then why not introduce the match expression first, and add block 
expressions (as a general concept) later? That way, we don't need all 
the special restrictions on when to use them, and can work out a 
consistent set of rules for them which can apply language-wide, rather 
than being constrained later by decisions we make half-implementing them 
now.

The ability to use them with short closure syntax would be very 
interesting, if the scoping/capture rules could be agreed.


>> it makes *all* the control flow blocks in Rust feel more natural to
>> developers coming from other languages.
> Same thing here. If you don't use the result value, it looks just like
> the switch. That's why I'd feel odd to require a semicolon.


Not really. In Rust, it's about making a whole bunch of control 
structures, which are already consistent with each other, more user 
friendly (but still consistent). In your proposal, it's about making one 
specific control structure look slightly more like other syntaxes in the 
same language, by adding a special case which applies nowhere else.

To be specific, in PHP, there is no "omitted semicolon" at the end of 
"if ($x) { y(); }" - that is just how the syntax is defined. There's no 
need to have a parser rule to allow it to look like C or Java, because 
it already does.


> This code is parsed like this:
>
> ```
> match($x) { 1 => ['foo', 'bar'] }
> [0];
> ```
>
> * statement list
>      * match expr
>      * array literal
>
> Note that we can't have ambiguous grammar since Bison would
> immediately expose it.


I'm not sure what you mean by "we can't have ambiguous grammar" - the 
code above *is* ambiguous, in that it could be defined to mean one of 
two things; what you've shown is which definition your implementation 
defines.

That resolution makes sense for that example, but consider some others:

// As proposed, parsed as two meaningless expression-statements; as a 
normal expression, would select and then invoke a callable
match($x) { 1 => 'print', 2 => 'var_dump' }
($x);

// Invalid under the proposed rule, but a valid method call if match was 
always a normal expression
match($x) { 1 => new Foo, 2 => new Bar }
->doSomething();


To be fair, the same limitation exists for closures, where this is invalid:

function($x) { echo $x; } ("Hello");

and you have to write this instead:

(function($x) { echo $x; }) ("Hello");


So I guess the above would follow the same rule to force expression context:

(match($x) { 1 => 'print', 2 => 'var_dump' })($x);

(match($x) { 1 => new Foo, 2 => new Bar })->doSomething();

The only downside is that omitting the parentheses wouldn't be an error, 
as with the closure case, it would just silently do nothing, which might 
be rather confusing. Dropping the special semicolon handling would mean 
it either did the expected thing or gave a parse error straight away.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]