Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126279
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 04 Feb 2025 08:51:20 +0100
To: internals@lists.php.net
Message-ID: <da29a750-9d34-428b-8356-8eedd629af0c@app.fastmail.com>
In-Reply-To: <febe86f4-db37-4ea0-84ef-a30d59d832af@app.fastmail.com>
References: <febe86f4-db37-4ea0-84ef-a30d59d832af@app.fastmail.com>
Subject: Re: [PHP-DEV] Pattern matching details questions
Content-Type: multipart/alternative;
 boundary=52015aa141ba450d847d373ceb75da25
From: rob@bottled.codes ("Rob Landers")

--52015aa141ba450d847d373ceb75da25
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2025, at 05:31, Larry Garfield wrote:
> Hi folks.  Ilija is still working on the implementation for the patter=
n matching RFC, which we want to complete before proposing it officially=
 in case we run into implementation challenges.
>=20
> Such as these, on which we'd like feedback on how to proceed.
>=20
> ## Object property patterns
>=20
> Consider this code snippet:
>=20
> class C {
>     public $prop =3D 42 is Foo{};
> }
>=20
> The parser could interpret this in multiple ways:
>=20
> * make a public property named $prop, with default value of "the resul=
t of `42 is Foo`" (which would be false), and then has an  empty (and th=
erefore invalid) property hook block
> * make a public property named $prop, with default value of "whatever =
the result of `42 is Foo {}`" (which would be false).
>=20
> Since the parser doesn't allow for ambiguity, this is not workable.  B=
ecause PHP uses only an LL(1) parser, there's no way to "determine from =
context" which is intended, eg, by saying "well the hook block is empty =
so it must have been part of the pattern before it."
>=20
> In practice, no one should be writing code like the above, as it's nee=
dlessly nonsensical (it's statically false in all cases), but the parser=
 doesn't know that.
>=20
> The only solution we've come up with is to not have object patterns, b=
ut have a property list pattern that can be compounded with a type patte=
rn.  Eg:
>=20
> $p is Point & {x: 5}
>=20
> Instead of what we have now:
>=20
> $p is Point{x: 5}
>=20
> Ilija says this will resolve the parsing issue.  It would also make it=
 possible to match `$p is {x: 5}`, which would not check the type of $p =
at all, just that it's an object with an $x property with value 5.  That=
 is arguably a useful feature in some cases, but does make the common ca=
se (matching type and properties) considerably more clunky.
>=20
> So, questions:
>=20
> 1. Would splitting the object pattern like that be acceptable?
> 2. Does someone have a really good alternate suggestion that wouldn't =
confuse the parser?
>=20
> ## Variable binding and pinning
>=20
> Previously there was much discussion about the syntax we wanted for th=
ese features.  In particular, variable binding means "pull a sub-value o=
ut of the matched value to its own variable, if the pattern matches."  V=
ariable pinning means "use some already-existing variable here to dynami=
cally form the pattern."  Naturally, these cannot both just be a variabl=
e name on their own, as that would be confusing (both for users and the =
engine).
>=20
> For example:
>=20
> $b =3D '12';
>=20
> if ($arr is ['a' =3D> assign to $a, 'b' =3D> assert is equal to $b]) {
>     print $a;
> }
>=20
> Based on my research[1], the overwhelming majority of languages use a =
bare variable name to indicate variable binding.  Only one language, Rub=
y, has variable pinning, which it indicates with a ^ prefix.  Following =
Ruby's lead, as the RFC text does right now, would yield:
>=20
> $b =3D '12';
>=20
> if ($arr is ['a' =3D> $a, 'b' =3D> ^$b]) {
>     print $a;
> }
>=20
> That approach would be most like other languages with pattern matching.
>=20
> However, there is a concern that it wouldn't be self-evident to PHP de=
vs, and the variable binding side should have the extra marker.  Ilija h=
as suggested &, as that's what's used for references, which would result=
 in:
>=20
> $b =3D '12';
>=20
> if ($arr is ['a' =3D> &$a, 'b' =3D> $b]) {
>     print $a;
> }
>=20
> There are two concerns with this approach.
>=20
> 1. The & could get confusing with an AND conjunction, eg, `$value is i=
nt & &$x` (which is how you would bind $value to $x iff it is an integer=
).
> 2. In practice, binding is almost certainly going to be vastly more co=
mmon than pinning, so it should likely have the shorter syntax.
>=20
> There are of course other prefixes that could be used, such as `let` (=
introduces a new keyword, possibly confusing as it wouldn't imply scope =
restrictions like in other languages) or `var` (no new keyword, but coul=
d still be confusing and it's not obvious which side should get it), but=
 ^ is probably the only single-character option.
>=20
> So, question:
>=20
> 1. Are you OK with the current Ruby-inspired syntax?  ($a means bind, =
^$b means pin.)
> 2. If not, have you a counter-proposal that would garner consensus?
>=20
>=20
> Thanks all.
>=20
> [1] https://github.com/Crell/php-rfcs/blob/master/pattern-matching/res=
earch.md
>=20
> --=20
>   Larry Garfield
>   larry@garfieldtech.com
>=20

Hey Larry,

Instead of symbols, why not use words?

We already have &&, but it looks like this uses & instead, which is a bi=
twise-and. But the language does have =E2=80=9Cand=E2=80=9D as a keyword=
. So instead of:

$value is int & &$x

It would be:

$value is int and &$x

Which removes the confusion you mentioned before (also for someone like =
me who uses bitwise-and quite a bit).

=E2=80=94 Rob
--52015aa141ba450d847d373ceb75da25
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Tue, Feb 4, 2025, at 05:31, Larry Garfield wrote:<br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi folks.&nbsp;=
 Ilija is still working on the implementation for the pattern matching R=
FC, which we want to complete before proposing it officially in case we =
run into implementation challenges.<br></div><div><br></div><div>Such as=
 these, on which we'd like feedback on how to proceed.<br></div><div><br=
></div><div>## Object property patterns<br></div><div><br></div><div>Con=
sider this code snippet:<br></div><div><br></div><div>class C {<br></div=
><div>&nbsp;&nbsp;&nbsp; public $prop =3D 42 is Foo{};<br></div><div>}<b=
r></div><div><br></div><div>The parser could interpret this in multiple =
ways:<br></div><div><br></div><div>* make a public property named $prop,=
 with default value of "the result of `42 is Foo`" (which would be false=
), and then has an&nbsp; empty (and therefore invalid) property hook blo=
ck<br></div><div>* make a public property named $prop, with default valu=
e of "whatever the result of `42 is Foo {}`" (which would be false).<br>=
</div><div><br></div><div>Since the parser doesn't allow for ambiguity, =
this is not workable.&nbsp; Because PHP uses only an LL(1) parser, there=
's no way to "determine from context" which is intended, eg, by saying "=
well the hook block is empty so it must have been part of the pattern be=
fore it."<br></div><div><br></div><div>In practice, no one should be wri=
ting code like the above, as it's needlessly nonsensical (it's staticall=
y false in all cases), but the parser doesn't know that.<br></div><div><=
br></div><div>The only solution we've come up with is to not have object=
 patterns, but have a property list pattern that can be compounded with =
a type pattern.&nbsp; Eg:<br></div><div><br></div><div>$p is Point &amp;=
 {x: 5}<br></div><div><br></div><div>Instead of what we have now:<br></d=
iv><div><br></div><div>$p is Point{x: 5}<br></div><div><br></div><div>Il=
ija says this will resolve the parsing issue.&nbsp; It would also make i=
t possible to match `$p is {x: 5}`, which would not check the type of $p=
 at all, just that it's an object with an $x property with value 5.&nbsp=
; That is arguably a useful feature in some cases, but does make the com=
mon case (matching type and properties) considerably more clunky.<br></d=
iv><div><br></div><div>So, questions:<br></div><div><br></div><div>1. Wo=
uld splitting the object pattern like that be acceptable?<br></div><div>=
2. Does someone have a really good alternate suggestion that wouldn't co=
nfuse the parser?<br></div><div><br></div><div>## Variable binding and p=
inning<br></div><div><br></div><div>Previously there was much discussion=
 about the syntax we wanted for these features.&nbsp; In particular, var=
iable binding means "pull a sub-value out of the matched value to its ow=
n variable, if the pattern matches."&nbsp; Variable pinning means "use s=
ome already-existing variable here to dynamically form the pattern."&nbs=
p; Naturally, these cannot both just be a variable name on their own, as=
 that would be confusing (both for users and the engine).<br></div><div>=
<br></div><div>For example:<br></div><div><br></div><div>$b =3D '12';<br=
></div><div><br></div><div>if ($arr is ['a' =3D&gt; assign to $a, 'b' =3D=
&gt; assert is equal to $b]) {<br></div><div>&nbsp;&nbsp;&nbsp; print $a=
;<br></div><div>}<br></div><div><br></div><div>Based on my research[1], =
the overwhelming majority of languages use a bare variable name to indic=
ate variable binding.&nbsp; Only one language, Ruby, has variable pinnin=
g, which it indicates with a ^ prefix.&nbsp; Following Ruby's lead, as t=
he RFC text does right now, would yield:<br></div><div><br></div><div>$b=
 =3D '12';<br></div><div><br></div><div>if ($arr is ['a' =3D&gt; $a, 'b'=
 =3D&gt; ^$b]) {<br></div><div>&nbsp;&nbsp;&nbsp; print $a;<br></div><di=
v>}<br></div><div><br></div><div>That approach would be most like other =
languages with pattern matching.<br></div><div><br></div><div>However, t=
here is a concern that it wouldn't be self-evident to PHP devs, and the =
variable binding side should have the extra marker.&nbsp; Ilija has sugg=
ested &amp;, as that's what's used for references, which would result in=
:<br></div><div><br></div><div>$b =3D '12';<br></div><div><br></div><div=
>if ($arr is ['a' =3D&gt; &amp;$a, 'b' =3D&gt; $b]) {<br></div><div>&nbs=
p;&nbsp;&nbsp; print $a;<br></div><div>}<br></div><div><br></div><div>Th=
ere are two concerns with this approach.<br></div><div><br></div><div>1.=
 The &amp; could get confusing with an AND conjunction, eg, `$value is i=
nt &amp; &amp;$x` (which is how you would bind $value to $x iff it is an=
 integer).<br></div><div>2. In practice, binding is almost certainly goi=
ng to be vastly more common than pinning, so it should likely have the s=
horter syntax.<br></div><div><br></div><div>There are of course other pr=
efixes that could be used, such as `let` (introduces a new keyword, poss=
ibly confusing as it wouldn't imply scope restrictions like in other lan=
guages) or `var` (no new keyword, but could still be confusing and it's =
not obvious which side should get it), but ^ is probably the only single=
-character option.<br></div><div><br></div><div>So, question:<br></div><=
div><br></div><div>1. Are you OK with the current Ruby-inspired syntax?&=
nbsp; ($a means bind, ^$b means pin.)<br></div><div>2. If not, have you =
a counter-proposal that would garner consensus?<br></div><div><br></div>=
<div><br></div><div>Thanks all.<br></div><div><br></div><div>[1]&nbsp;<a=
 href=3D"https://github.com/Crell/php-rfcs/blob/master/pattern-matching/=
research.md">https://github.com/Crell/php-rfcs/blob/master/pattern-match=
ing/research.md</a><br></div><div><br></div><div>--&nbsp;<br></div><div>=
&nbsp; Larry Garfield<br></div><div>&nbsp;&nbsp;<a href=3D"mailto:larry@=
garfieldtech.com">larry@garfieldtech.com</a><br></div><div><br></div></b=
lockquote><div><br></div><div>Hey Larry,<br></div><div><br></div><div>In=
stead of symbols, why not use words?<br></div><div><br></div><div>We alr=
eady have &amp;&amp;, but it looks like this uses &amp; instead, which i=
s a bitwise-and. But the language does have =E2=80=9Cand=E2=80=9D as a k=
eyword. So instead of:<br></div><div><br></div><div>$value is int &amp; =
&amp;$x<br></div><div><br></div><div>It would be:<br></div><div><br></di=
v><div>$value is int and &amp;$x<br></div><div><br></div><div>Which remo=
ves the confusion you mentioned before (also for someone like me who use=
s bitwise-and quite a bit).</div><div><br></div><div id=3D"sig121229152"=
>=E2=80=94 Rob<br></div></body></html>
--52015aa141ba450d847d373ceb75da25--