Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126288
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 04 Feb 2025 15:16:57 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <3bb77a10-f716-4729-9bc4-4b87772598a5@app.fastmail.com>
In-Reply-To: <25b1011b-b2c4-4f5c-8e83-694c59ee29eb@mabe.berlin>
References: <febe86f4-db37-4ea0-84ef-a30d59d832af@app.fastmail.com>
 <da29a750-9d34-428b-8356-8eedd629af0c@app.fastmail.com>
 <25b1011b-b2c4-4f5c-8e83-694c59ee29eb@mabe.berlin>
Subject: Re: [PHP-DEV] Pattern matching details questions
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 4, 2025, at 1:14 PM, Marc Bennewitz wrote:
> On 04.02.25 08:51, Rob Landers wrote:
>>=20
>>=20
>> On Tue, Feb 4, 2025, at 05:31, Larry Garfield wrote:
>>> Hi folks.  Ilija is still working on the implementation for the patt=
ern matching RFC, which we want to complete before proposing it official=
ly in case we run into implementation challenges.
>>>=20
>>> Such as these, on which we'd like feedback on how to proceed.


>>> [1] https://github.com/Crell/php-rfcs/blob/master/pattern-matching/r=
esearch.md
>>>=20
>>> --=20
>>>   Larry Garfield
>>>   larry@garfieldtech.com
>>>=20
>>=20
>> Hey Larry,
>>=20
>> Instead of symbols, why not use words?
>>=20
>> We already have &&, but it looks like this uses & instead, which is a=
 bitwise-and. But the language does have =E2=80=9Cand=E2=80=9D as a keyw=
ord. So instead of:
>>=20
>> $value is int & &$x
>>=20
>> It would be:
>>=20
>> $value is int and &$x
>>=20
>> Which removes the confusion you mentioned before (also for someone li=
ke me who uses bitwise-and quite a bit).
>>=20
>> =E2=80=94 Rob

Patterns are deliberately designed as a superset of existing DNF types. =
 You can already have a type of Foo&Bar, so we want the pattern for "ins=
tanceof Foo || instanceof Bar" to be the same.  That means & and | for c=
onjunctions is necessary.  Also supporting "and" and "or" would technica=
lly be possible, but wouldn't resolve the issue (since & would still be =
needed either way) and would just add more complication, confusion, and =
inconsistency.  I don't think that's viable.

> Is it possible to use the already added "is", like:
>
> $arr is ['a' =3D> $a, 'b' =3D> is $b]=20

Would that inner "is" be capturing $b, or injecting $b?  It just pushes =
the same question down a level, and with an LL(1) parser we cannot tell =
what context we're in.  (If we could, there would be no problem.) =20

> Or, to use the already known uniform variable syntax "{$var}", like:
>
> $arr is ['a' =3D> $a, 'b' =3D> {$b}]=20

That looks like it could be confused with a property pattern, assuming w=
e end up doing that for part 1.  In which case, is that "index b maps to=
 an object with one property, and bind that property" or "index b maps t=
o an object with one property, and that property should be the value of =
$b"?  Or "index b maps to the value of $b"?  That doesn't seem any less =
confusing, for the engine or human.

--Larry Garfield