Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114499
MIME-Version: 1.0
References: <f3d20496-c560-42b7-9a0d-8672b3cafa7d@www.fastmail.com>
 <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com> <CAN2symhHys1uADWnOfraEA3SiM8_57=JttWhgOJ0Kh7nwt4R+g@mail.gmail.com>
 <CAEMvS4FbtPqdeySsVWm=Gub1BNiv+OCiB2oGL-+aZvBH7hmisA@mail.gmail.com>
 <CAEMvS4F+AbxPJQ5ctLONptECvmkdrzT42oU4rDOjtD2dC_jEJw@mail.gmail.com> <09B663C3-E21D-432B-BB7F-78312F827C30@newclarity.net>
In-Reply-To: <09B663C3-E21D-432B-BB7F-78312F827C30@newclarity.net>
Date: Mon, 17 May 2021 16:50:06 +0200
Message-ID: <CAC5V6gjDfqxBPYF_ejVTboPOGV9rg0ArAqOGGO3mPG6nqEPevw@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Hossein Baghayi <hossein.baghayi@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049093f05c287b685"
Subject: Re: [PHP-DEV] [RFC] Partial function application
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--00000000000049093f05c287b685
Content-Type: text/plain; charset="UTF-8"

On Mon, May 17, 2021 at 6:58 AM Mike Schinkel <mike@newclarity.net> wrote:

>
> > On May 16, 2021, at 10:43 PM, Hossein Baghayi <hossein.baghayi@gmail.com>
> wrote:
> >
> > On Sat, 15 May 2021 at 09:03, Hossein Baghayi <hossein.baghayi@gmail.com
> >
> > wrote:
> >
> >> Providing ? as a means of placeholder for some arguments and ignoring
> the
> >> rest could complicate the readability in my opinion.
> >> Maybe we should move (?) out of the arguments list as a means of
> creating
> >> a partial.
> >>
> >> What I realized is that we need a way of signaling partial function
> >> creation. Be it foo(?) or foo(?, ?, ?) or however many ? is added there,
> >> which does not convey any meaning and also doesn't produce any sort of
> >> error!
> >>
> >> Say instead of foo(?) we had ?foo().
> >> Since we have named parameters it could help us in providing some of the
> >> arguments and deferring the rest.
> >>
> >> For instance:
> >> ```
> >> function foo($x, $y, ...$z) {}
> >>
> >> ?foo(); // causes a partial
> >> ?foo(y: '..'); // also causes a partial
> >> ```
> >>
> >> This way we wouldn't need to worry about the number of ? added to
> >> arguments list.
> >> It may also help in avoiding future PSRs in telling us how many ? we
> >> should put in there :)
> >>
> >
> > In addition to these, I was thinking of 2 other cases in which changing
> the
> > current proposal might be helpful.
> >
> > 1- When there is a parameterless function (an expensive operation maybe).
> > 2- When all parameters are passed but the function is not expected to be
> > called yet.
> >
> > In the case of a parameterless function, maybe it is an expensive
> function
> > call and we need to defer calling it.
> > Maybe all we need is to hold a reference to it and pass it around?
> > With the current proposal, I do not know if it is possible or not. Since
> > there are no parameters defined.
> > ```
> > function with_expensive_operations_lurking_inside() {...}
> > ````
> > Can we or should we call this function this way:
> > ```
> > $ref = with_expensive_operations_lurking_inside(?);
> > ```
> > It feels odd having to provide parameters when there is none needed.
> >
> >
> > For the other use case where all parameters are passed but is not
> expected
> > to be called yet:
> > Maybe providing parameters and setting it up is not our responsibility.
> > ```
> > function expensive_or_not($a, $b, $c) {...}
> > $do_not_get_called_please = expensive_or_not(1, 2, 3, ?); // with an
> extra
> > parameter as to mark as partial!
> > $do_not_get_called_please = expensive_or_not(?, 1, 2, 3); // or maybe
> this
> > way?!
> > ```
> >
> > Well, I was thinking that by changing the proposed syntax we could
> achieve
> > what is proposed and a little bit more.
> > Also we wouldn't need to worry about the number of ? needed as arguments.
> > Since all we need is to mark the return type as partial (closure) on the
> > fly and grab hold of what is passed as arguments.
> >
> > There are some different syntaxes that come to my mind:
> > We could still use ? but outside of the arguments list?
> > ```
> > $partial = xyx?(..);
> > $partial = ?xyx(..);
> > ```
> > or maybe different symbols:
> > ```
> > $partial = :xyz(..);
> > ```
> >
> > We might be able to even cast the return type:
> > ```
> > $partial = (?) xyz(..);
> > $partial = (partial) xyz(..);
> > $partial = (fn) xyz(..);
> > ```
>
> Casting is another interesting approach that does feel more consistent
> with the existing language.
>
> Since it *is* creating a closure, wouldn't this make the most sense?
>
> $partial = (closure) abc();
>

Ouch! definitely NOT!


> $partial = (closure) xyz(?,24);
>

> -Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
But I agree that these two cases "don't feel quite right":

```
function noParam() {/*...*/}

$p = noParam(?); /* looks like there's 1 param, to be passed on call */
```

```
function threeParams($a, $b, $c) {/*...*/}

$p = threeParams(1, 2, 3, ?); /* looks like there's 4 params, with the last
one to be passed on call */
```

(both would be called as `$p()`, i.e. without any arg).  Here we had to add
a `?` only for "technical" reasons.

More generally I also agree that `?` having two different
meanings/behaviors in e.g. `f(?, 2)` [or `f(1, ?, 3)`] vs `f(1, ?)` --
namely: "exactly 1 arg" vs "0+ args" -- is confusing.
I think I too would prefer `?` to only mean "exactly 1 arg", and
  - either have another token for "0+ args" (e.g.: `f(?, 2)` [and `f(1, ?,
3)`] vs `f(1, ...)`, and also `noParam(...)` and `threeParams(1, 2, 3,
...)` )
  - or have another syntax like Hossein first suggested (e.g.: `*f(?, 2)`
[and `*f(1, ?, 3)`] vs `*f(1)`, and also `*noParam()` and `*threeParams(1,
2, 3)`).
Unless there are compelling (or at least convincing) reasons against?

Thanks,

-- 
Guilliam Xavier

--00000000000049093f05c287b685--