Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123877 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id EFF711A009C for ; Wed, 26 Jun 2024 18:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719426135; bh=XoK7DG4UnJgILpw90y9NKUEVV1G+XAAtj7wfdd0CRto=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=AExmX8x9+MlickgQ8CHoZzybBN2u1z7ZyhmNEeDghjLmb4Hy2Yx28HVFX4D80ULer cRNtnm2cSyXcrGmC3A+7JNMlWQ7SPkdObJBmSVXc6neRS5EucnDlV8ZBl/eOmriAIl 8GkXnRYkkBvvpgRURdi8hdeGEMq7WXcJkkHzXVyhlz9OKzgCIeIHs2+sHUxGKggf3q Rhma5LywQ1rlykySBhtlZRWpsSN1K9KNd9Zto40YiNY2fxW7qnNyUGWEEdHAprEJdE so4umZcnZpAeoWPOeFTaMySpB9fJu14sUH03B507QLP+qjv4cZJ4C7HMg+w55Ajdzh IEY1HTaukw23w== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4D09F180779 for ; Wed, 26 Jun 2024 18:22:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 26 Jun 2024 18:22:13 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-375af3538f2so29643645ab.3 for ; Wed, 26 Jun 2024 11:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miles.systems; s=google; t=1719426055; x=1720030855; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=cW9zjoX68a0Xl2EW3/dss977tEMPO+3Z+XBn5Gk+sGs=; b=WeoYJA2QVEMfH02QYPAW9Hwxq5A+ZycdjZGzQDr03sAnfDLf/AtYniyec4bXS8D2SP yK09+ibmY7VAhfZwvesCNGhgs01uh8DjjF5OAmojjpNzUE2Y2U8JDSP6bupnmG4z+jr5 mZBM3uiBozD8AwdBuW5AwvGdJzHiggvTnfeNRqLm+bxWafjj3YCW5QOHPNr5g0h86+xN e6ue5e1urCmAinE2mMTf45WaXq8ZHnmpjP1ycRTa690qslUAXqa/FtCevGTnmpqeh4Pe nBJoxlPWJrbF5NLtZRkwjPUl+u/0wSvphLP0iHysRy0vce+2vxBnWuk5H64zsxPGFzY6 lM6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719426055; x=1720030855; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cW9zjoX68a0Xl2EW3/dss977tEMPO+3Z+XBn5Gk+sGs=; b=Pe5PXHT+zFAqvs2IQ/9tprbkyUgJeHo4ah9ina7CA9B2ItyZ8cqNOa2W1SfAxRs6Gd zwHfzmfWKwkco6JaQQNrVaGNR8WrDYsZfgy+aO/jerjp23/4NdbQ8u1d75ugr3d+HoMd BJsTXxjC1XY52il5RMeWeKDgmptNUJqOhD2Gjqj1b+x2iWelHzc27auS+hicq31BgfUc GKvhtScrklPNkDjRtmMFa6O++f5diNi9liUGF6UGGlP/57e+cW5K7HQuVuJh7ZfRRt4a XX4xYeXs5Cm0bjRM0R7K73wiBjwP0O3vif2eeTz6lwisCggLMvtwJCuBdDJ81HrsduYq YJGQ== X-Gm-Message-State: AOJu0Ywsd56+KAYcdlDreE4AZNoyPmTrk/EcXYK0pnJ4/FShRdt+Chz9 EBK5M1DyGsvdM5EVGLSZaLeZ5yuDtIy32EfUJr2745uvmIeVNyFGz4Cv6NOIupA= X-Google-Smtp-Source: AGHT+IFfLZEy4z5UFHQzqhY3X8KaI23F7cfCG7gKTlEnEsMRc4h5g2ro8BTiXqCAYbCL8br2T9rHLQ== X-Received: by 2002:a05:6e02:b29:b0:376:1cf6:6be4 with SMTP id e9e14a558f8ab-3763f5bedebmr148731435ab.14.1719426055105; Wed, 26 Jun 2024 11:20:55 -0700 (PDT) Received: from smtpclient.apple ([2601:283:4600:6770:1058:1c9c:6c8b:173a]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3762f38b9c4sm28293245ab.59.2024.06.26.11.20.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2024 11:20:54 -0700 (PDT) Message-ID: <45FCF811-902A-4AC5-8499-0EA0B69A426F@miles.systems> Content-Type: multipart/alternative; boundary="Apple-Mail=_C7061E31-E31C-441D-9F5F-134AEFC59BB9" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching Date: Wed, 26 Jun 2024 12:20:43 -0600 In-Reply-To: <0F7B09EC-C38E-4B49-9137-1FB3EA5231AC@miles.systems> Cc: php internals To: Larry Garfield References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com> <0F7B09EC-C38E-4B49-9137-1FB3EA5231AC@miles.systems> X-Mailer: Apple Mail (2.3774.600.62) From: richard@miles.systems (Richard Miles) --Apple-Mail=_C7061E31-E31C-441D-9F5F-134AEFC59BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After a coffee break, I think this is how the language could do this in = a semantically pleasing way.=20 interface iArrayA ['a' =3D> string ] interface iArrayB extends iArrayA ['b' =3D> string ] $arr is iArrayA &| iArrayB Best, Richard Miles > On Jun 26, 2024, at 11:57=E2=80=AFAM, Richard Miles = wrote: >=20 > =E2=80=9CArray-application will also be pushed to future-scope=E2=80=9D >=20 >=20 > Dang, this is what I was looking forward to the most. Helping set some = precedent on this issue, and this is a solid start. I=E2=80=99ve been = thinking about what it would look like for strictly typed arrays in PHP = for a while now. I think a custom implantation like SqlObjectStorage or = SplFixedArray could help performance since we now have a fixed list and = no need for a hash table, and it may solve some complexity in = implementation. This is slightly off-topic, but if anyone is interested = in working on a typed arrays initiative, please contact me directly.=20 >=20 >=20 > That said, I agree with Robert Landers, who wrote the following: >=20 > There's no need to use `?` to check for existence on a key, so this: >=20 > $arr is ['a' =3D> string, ?'b' =3D> string, ...]; >=20 > should be this: >=20 > $arr is ['a' =3D> string, 'b' =3D> ?string, =E2=80=A6]; >=20 > ______ >=20 > Chuck Adams cleared that up with: > The first means b is an optional key, but if it=E2=80=99s there, can = only be a string. The second says b is a required key, but it may be a = string or null. If there were a binding involved, that determines the = type of the binding in incompatible ways. > ______ >=20 > I think there is a need to ensure a key does not exist even if we=E2=80=99= re not happy about this syntax, but if not having `$arr is ['a' =3D> = string, 'b' =3D> ?string, =E2=80=A6]` would still make me very happy.=20 >=20 > Best, >=20 > Richard Miles >=20 >=20 >> On Jun 24, 2024, at 5:31=E2=80=AFPM, Larry Garfield = wrote: >>=20 >> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: >>=20 >>> To that end, we're looking for *very high level* feedback on this = RFC: >>>=20 >>> https://wiki.php.net/rfc/pattern-matching >>=20 >> Hi folks. Thank you to those who have offered feedback so far. = Based on the discussion, here's what we're thinking of doing (still = subject to change, of course): >>=20 >> * We're going to move `as` to future-scope. There's enough weirdness = around it that is independent of pattern matching itself that it will = likely require its own discussion and RFC, and may or may not involve = full pattern support. >>=20 >> * Similarly, we're going to hold off on the weak-mode flag. It = sounds like the language needs to do more to fix the definition of "weak = mode" before it's really viable. :-( On the plus side, if the type = system itself ever adds support for a "coercion permitted" flag, = patterns should inherit that naturally, I think. >>=20 >> * Array-application will also be pushed to future-scope. Again, = there's enough type-system tie in here that is tangential to patterns = that we'll pick that fight later. >>=20 >> * Ilija and I have discussed regex patterns a bit further, and it = sounds like they=E2=80=99re going to be rather complicated to implement. = Even assuming we agree on the syntax for it, it would be a substantial = amount of code to support. (It=E2=80=99s not like types or literals or = range where we can just drop something pre-existing into a new = function.) So we=E2=80=99re going to hold off on this one for now, = though it does seem like a high-priority follow-up for the future. = (Which doesn=E2=80=99t have to be us!) >>=20 >> So let's not discuss the above items further at this point. >>=20 >> * I'm going to do some additional research into other languages to = see how they handle binding vs using variables from scope, and what = syntax markers they use and where. Once we have a better sense of what = is out there and is known to work, we can make a more informed plan for = what we should do in PHP. (Whether using a variable from scope in the = pattern is part of the initial RFC is still an open question, but we do = need to design it alongside the capture part to ensure they don't = conflict.) Stay tuned on this front. >>=20 >> * We've removed the dedicated wildcard pattern, as it's equivalent to = `mixed`. If there's interest, we're open to having a secondary vote to = bring it back as a short-hand pattern. It's trivial to implement and we = don't have strong feelings either way. >>=20 >> * There's not been much discussion of range patterns. Anyone want to = weigh in on those? >>=20 >> * The placement of `is` on `match()` is still an open question. >>=20 >> * No one has really weighed in on nested patterns for captured = variables. Any thoughts there? >>=20 >> * I=E2=80=99ve seen a suggestion for capturing the =E2=80=9Crest=E2=80=9D= of an array when using =E2=80=A6 That=E2=80=99s an interesting idea, = and we=E2=80=99ll explore it, though it looks like it may have some = interesting implications that push it to future scope. It feels like a = nice-to-have. >>=20 >> Thanks all. >>=20 >> --Larry Garfield >=20 --Apple-Mail=_C7061E31-E31C-441D-9F5F-134AEFC59BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
After a coffee break, I think this is how the =
language could do this in a semantically pleasing way. 

interface iArrayA ['a' =3D> string ]
interface iArrayB extends iArrayA ['b' =3D> string ]

$arr is iArrayA &| iArrayB

Best,
Richard =
Miles

On Jun 26, 2024, at 11:57=E2=80=AF= AM, Richard Miles <richard@miles.systems> wrote:

=E2=80=9CArray-application will also be pushed to = future-scope=E2=80=9D


Dang, this is what I = was looking forward to the most. Helping set some precedent on this = issue, and this is a solid start. I=E2=80=99ve been thinking about what = it would look like for strictly typed arrays in PHP for a while now. I = think a custom implantation like SqlObjectStorage or SplFixedArray could = help performance since we now have a fixed list and no need for a hash = table, and it may solve some complexity in implementation. This is = slightly off-topic, but if anyone is interested in working on a typed = arrays initiative, please contact me = directly. 


That said, I = agree with Robert Landers, who wrote the = following:

There's no need to use `?` to check = for existence on a key, so this:

$arr is ['a' =3D> string, = ?'b' =3D> string, ...];

should be this:

$arr is ['a' = =3D> string, 'b' =3D> ?string, = =E2=80=A6];

______

Chuck= Adams cleared that up with:
The first means b is an optional = key, but if it=E2=80=99s there, can only be a string. The second says b = is a required key, but it may be a string or null. If there were a = binding involved, that determines the type of the binding in = incompatible ways.
______

I think = there is a need to ensure a key does not exist even if we=E2=80=99re not = happy about this syntax, but if not having `$arr is ['a' =3D> string, = 'b' =3D> ?string, =E2=80=A6]` would still make me very = happy. 

Best,

Richard = Miles


On Jun 24, 2024, at 5:31=E2=80=AFP= M, Larry Garfield <larry@garfieldtech.com> wrote:

On Thu, Jun 20, 2024, at = 5:38 PM, Larry Garfield wrote:

To that = end, we're looking for *very high level* feedback on this = RFC:

https://wiki.php.net/rfc/pattern-matching

= Hi folks.  Thank you to those who have offered feedback so far. =  Based on the discussion, here's what we're thinking of doing = (still subject to change, of course):

* We're going to move `as` = to future-scope.  There's enough weirdness around it that is = independent of pattern matching itself that it will likely require its = own discussion and RFC, and may or may not involve full pattern = support.

* Similarly, we're going to hold off on the weak-mode = flag.  It sounds like the language needs to do more to fix the = definition of "weak mode" before it's really viable. :-(  On the = plus side, if the type system itself ever adds support for a "coercion = permitted" flag, patterns should inherit that naturally, I = think.

* Array-application will also be pushed to future-scope. =  Again, there's enough type-system tie in here that is tangential = to patterns that we'll pick that fight later.

* Ilija and I have = discussed regex patterns a bit further, and it sounds like they=E2=80=99re= going to be rather complicated to implement.  Even assuming we = agree on the syntax for it, it would be a substantial amount of code to = support.  (It=E2=80=99s not like types or literals or range where = we can just drop something pre-existing into a new function.)  So = we=E2=80=99re going to hold off on this one for now, though it does seem = like a high-priority follow-up for the future.  (Which doesn=E2=80=99= t have to be us!)

So let's not discuss the above items further at = this point.

* I'm going to do some additional research into other = languages to see how they handle binding vs using variables from scope, = and what syntax markers they use and where.  Once we have a better = sense of what is out there and is known to work, we can make a more = informed plan for what we should do in PHP.  (Whether using a = variable from scope in the pattern is part of the initial RFC is still = an open question, but we do need to design it alongside the capture part = to ensure they don't conflict.)  Stay tuned on this front.

* = We've removed the dedicated wildcard pattern, as it's equivalent to = `mixed`.  If there's interest, we're open to having a secondary = vote to bring it back as a short-hand pattern.  It's trivial to = implement and we don't have strong feelings either way.

* There's = not been much discussion of range patterns.  Anyone want to weigh = in on those?

* The placement of `is` on `match()` is still an = open question.

* No one has really weighed in on nested patterns = for captured variables.  Any thoughts there?

* I=E2=80=99ve = seen a suggestion for capturing the =E2=80=9Crest=E2=80=9D of an array = when using =E2=80=A6  That=E2=80=99s an interesting idea, and = we=E2=80=99ll explore it, though it looks like it may have some = interesting implications that push it to future scope.  It feels = like a nice-to-have.

Thanks all.

--Larry = Garfield


= --Apple-Mail=_C7061E31-E31C-441D-9F5F-134AEFC59BB9--