Re: [PHP-DEV] [RFC] Partial function application
> Requiring additional trailing argument placeholders or adding an
> additional token `...?` unnecessarily complicates things, burdens the
> user, and only serves to further promote misunderstanding.
>
> 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 :)
Re: [PHP-DEV] [RFC] Partial function application
On May 14, 2021, at 7:36 PM, Larry Garfield wrote: > > On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote: >> >>> On May 14, 2021, at 7:00 PM, Larry Garfield wrote: >>> >>> Is that actually going to come up? Given that PHP functions (at least >>> user-space ones) accept extra trailing arguments and just let them fall >>> off, I would *expect* a closure that way to do the same. Named arguments >>> continue that, I believe, by just ignoring any variadic arguments that do >>> not match a parameter in the function. It seems odd to go back on that >>> behavior now. >> >> I don't consider forwarding extra arguments an issue. I briefly was >> thinking it might be nice to be explicit about the number of arguments >> a partial would accept, but you convinced me otherwise in R11, so I >> think we're on the same page here. >> >>> >>> I can't speak for the others, but I could tolerate making "more than one >>> extra ? beyond the end of the parameter list is an error", potentially, as >>> at that point they're redundant. But if a function has, say, 4 params, >>> then fourParams(1, 3, ?) is a convenient way to say "and placeholder >>> everything else". Especially in dynamic cases like Nicolas pointed out, >>> you may not necessarily know how many arguments there are. >> >> With what I proposed in my last email, `fourParams(1, 3, ?)` is >> acceptable, there's nothing superfluous there. At least one ? is needed >> to declare a partial. Similarly, a partial for a no parameter function: >> `$partial = functionTakingNoParams(?)`. Or even a partial with args >> bound to all four params: `fourParams(1, 2, 3, 4, ?)`. >> >> What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless. >> >> I think you've convinced me that one-for-one matching on ? is >> burdensome, but the above is a happy medium perhaps? > > I'd be OK with "no more than one trailing ? in excess of what the underlying > callable has." (Which means if you don't know, just stick one ? at the end > and you know it will work.) I think multiple trailing ? should be an error, otherwise how am I suppose to know at a glance if a partial declaration will error? Plus it’s adding multiple ways to declare the same thing, which I was hoping to avoid. fourParams(1, 2, ?); // OK fourParams(1, 2, ?, ?); // OK for you, should error to me fourParams(1, 2, ?, ?, ?); // Again OK for you, should error to me fourParams(1, 2, ?, ?, ?, ?); // Error for both What value is gained in allowing any of those but the first? I’d also be fine allowing a trailing ? in any declaration. It’s unnecessary, but one could argue that it’s consistent to allow a trailing ? in any partial, since it’s required for some. fourParams(?, 2, ?); // Could error, but probably fine for consistency Aaron Piotrowski
Re: [PHP-DEV] [RFC] Partial function application
On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote: > > > On May 14, 2021, at 7:00 PM, Larry Garfield wrote: > > > > Is that actually going to come up? Given that PHP functions (at least > > user-space ones) accept extra trailing arguments and just let them fall > > off, I would *expect* a closure that way to do the same. Named arguments > > continue that, I believe, by just ignoring any variadic arguments that do > > not match a parameter in the function. It seems odd to go back on that > > behavior now. > > I don't consider forwarding extra arguments an issue. I briefly was > thinking it might be nice to be explicit about the number of arguments > a partial would accept, but you convinced me otherwise in R11, so I > think we're on the same page here. > > > > > I can't speak for the others, but I could tolerate making "more than one > > extra ? beyond the end of the parameter list is an error", potentially, as > > at that point they're redundant. But if a function has, say, 4 params, > > then fourParams(1, 3, ?) is a convenient way to say "and placeholder > > everything else". Especially in dynamic cases like Nicolas pointed out, > > you may not necessarily know how many arguments there are. > > With what I proposed in my last email, `fourParams(1, 3, ?)` is > acceptable, there's nothing superfluous there. At least one ? is needed > to declare a partial. Similarly, a partial for a no parameter function: > `$partial = functionTakingNoParams(?)`. Or even a partial with args > bound to all four params: `fourParams(1, 2, 3, 4, ?)`. > > What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless. > > I think you've convinced me that one-for-one matching on ? is > burdensome, but the above is a happy medium perhaps? I'd be OK with "no more than one trailing ? in excess of what the underlying callable has." (Which means if you don't know, just stick one ? at the end and you know it will work.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 7:00 PM, Larry Garfield wrote: > > Is that actually going to come up? Given that PHP functions (at least > user-space ones) accept extra trailing arguments and just let them fall off, > I would *expect* a closure that way to do the same. Named arguments continue > that, I believe, by just ignoring any variadic arguments that do not match a > parameter in the function. It seems odd to go back on that behavior now. I don't consider forwarding extra arguments an issue. I briefly was thinking it might be nice to be explicit about the number of arguments a partial would accept, but you convinced me otherwise in R11, so I think we're on the same page here. > > I can't speak for the others, but I could tolerate making "more than one > extra ? beyond the end of the parameter list is an error", potentially, as at > that point they're redundant. But if a function has, say, 4 params, then > fourParams(1, 3, ?) is a convenient way to say "and placeholder everything > else". Especially in dynamic cases like Nicolas pointed out, you may not > necessarily know how many arguments there are. With what I proposed in my last email, `fourParams(1, 3, ?)` is acceptable, there's nothing superfluous there. At least one ? is needed to declare a partial. Similarly, a partial for a no parameter function: `$partial = functionTakingNoParams(?)`. Or even a partial with args bound to all four params: `fourParams(1, 2, 3, 4, ?)`. What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless. I think you've convinced me that one-for-one matching on ? is burdensome, but the above is a happy medium perhaps? Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On 15/05/2021 01:00, Larry Garfield wrote: I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a convenient way to say "and placeholder everything else". Fortunately, we already have an existing and recognised way of saying "and everything else" https://www.php.net/manua/en/functions.arguments.php#functions.variablearg-list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
Mark Randall: > Based on discussions in R11 there seems to be broad agreement that ? > should represent a single argument, and ...? should represent everything > else (including no arguments). This is incorrect. There were a few people arguing for that, but there was far from a consensus on that point. None of the RFC authors were convinced of the arguments given, for example. On Fri, May 14, 2021, at 6:44 PM, Aaron Piotrowski wrote: > > > On May 14, 2021, at 6:09 PM, Paul Crovella wrote: > >> Or perhaps should the partial declaration should error, as it should have > >> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all > >> required arguments to foo. > > > > I think this highlights where the misunderstanding of this feature is. > > Partial application is about binding arguments. ? isn't an argument, > > it's an argument placeholder. It does two things: signals to create a > > closure wrapping the function rather than calling it immediately, and > > holds a position in the argument list so that an argument further to > > the right can be fixed (bound) at that time. Arguments are bound; > > argument placeholders are not, they exist only for convenience. The > > syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments > > to it, it simply creates a closure that'll pass along 42 at the > > appropriate argument position along with whatever else it's provided > > with. > > > > Requiring additional trailing argument placeholders or adding an > > additional token `...?` unnecessarily complicates things, burdens the > > user, and only serves to further promote misunderstanding. > > My issue is the dual-meaning of ? in the current proposal. In `foo(?, > 42)`, the ? represents a single argument, but adding a trailing ? (such > as in `foo(?, 42, ?)`) represents any number of arguments. Would it > perhaps make sense to make superfluous ? markers an error? > > foo(?); // Fine, needed to define a partial with no bound args. > foo(?, 42); // Ok, binds second arg. > foo(?, ?, 42); // Ok, binds third arg. > foo(?, 42, ?); // Error, unnecessary placeholder. > foo(?, ?); // Error, unnecessary placeholder. > > The intention here is to keep the syntax unambiguous. > > foo(?) == foo(?, ?) == foo(?, ?, ?) and so forth is not going to be > obvious to everyone, so why allow meaningless and misleading syntax. Is that actually going to come up? Given that PHP functions (at least user-space ones) accept extra trailing arguments and just let them fall off, I would *expect* a closure that way to do the same. Named arguments continue that, I believe, by just ignoring any variadic arguments that do not match a parameter in the function. It seems odd to go back on that behavior now. I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a convenient way to say "and placeholder everything else". Especially in dynamic cases like Nicolas pointed out, you may not necessarily know how many arguments there are. As Paul noted above, this isn't a syntax for calling a function; it's effectively an even-shorter-hand way to write a short lambda. The rest of the closure construction is derived from the function being partially applied. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 6:09 PM, Paul Crovella wrote:
>
> On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote:
>>
>> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
>> `$partial = foo(?, 42)`.
>>
>> If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z`
>> or should the call error as providing too few arguments?
>
> The 8 passes along to $z. There is no error, all required arguments
> have been provided.
In the current proposal, yes. In a hypothetical implementation where ?
represented a single argument, I was asking what made sense. In that situation,
I think 8 passing along still makes sense.
>
>> Or perhaps should the partial declaration should error, as it should have
>> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all
>> required arguments to foo.
>
> I think this highlights where the misunderstanding of this feature is.
> Partial application is about binding arguments. ? isn't an argument,
> it's an argument placeholder. It does two things: signals to create a
> closure wrapping the function rather than calling it immediately, and
> holds a position in the argument list so that an argument further to
> the right can be fixed (bound) at that time. Arguments are bound;
> argument placeholders are not, they exist only for convenience. The
> syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments
> to it, it simply creates a closure that'll pass along 42 at the
> appropriate argument position along with whatever else it's provided
> with.
>
> Requiring additional trailing argument placeholders or adding an
> additional token `...?` unnecessarily complicates things, burdens the
> user, and only serves to further promote misunderstanding.
>
My issue is the dual-meaning of ? in the current proposal. In `foo(?, 42)`, the
? represents a single argument, but adding a trailing ? (such as in `foo(?, 42,
?)`) represents any number of arguments. Would it perhaps make sense to make
superfluous ? markers an error?
foo(?); // Fine, needed to define a partial with no bound args.
foo(?, 42); // Ok, binds second arg.
foo(?, ?, 42); // Ok, binds third arg.
foo(?, 42, ?); // Error, unnecessary placeholder.
foo(?, ?); // Error, unnecessary placeholder.
The intention here is to keep the syntax unambiguous.
foo(?) == foo(?, ?) == foo(?, ?, ?) and so forth is not going to be obvious to
everyone, so why allow meaningless and misleading syntax.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote:
>
> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
> `$partial = foo(?, 42)`.
>
> If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z`
> or should the call error as providing too few arguments?
The 8 passes along to $z. There is no error, all required arguments
have been provided.
> Or perhaps should the partial declaration should error, as it should have
> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all
> required arguments to foo.
I think this highlights where the misunderstanding of this feature is.
Partial application is about binding arguments. ? isn't an argument,
it's an argument placeholder. It does two things: signals to create a
closure wrapping the function rather than calling it immediately, and
holds a position in the argument list so that an argument further to
the right can be fixed (bound) at that time. Arguments are bound;
argument placeholders are not, they exist only for convenience. The
syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments
to it, it simply creates a closure that'll pass along 42 at the
appropriate argument position along with whatever else it's provided
with.
Requiring additional trailing argument placeholders or adding an
additional token `...?` unnecessarily complicates things, burdens the
user, and only serves to further promote misunderstanding.
>
> Cheers,
> Aaron Piotrowski
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On 14/05/2021 22:48, Aaron Piotrowski wrote: I think it’s reasonable to allow passing more arguments to a partial since user-defined functions and closures allow this without error. But only userland functions, a relic from when func_get_args was the only way to handle varaible numbers of arguments. The documentation officially discourages func_get_args in favour of ...$ so I can definitely forsee the option of us deprecating that mechanism sometime in 8.x and and removing it in 9.0. I don't think it likely that it would go the other way of allowing unlimited arguments to internal functions. That being the case, IMO it makes more sense to introduce partials with the same behaviour as internal functions, passing more functions than specified (including partial arguments) should error. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
> On May 14, 2021, at 4:18 PM, Mark Randall wrote:
>
>
> Passing more arguments than the partial defines would result in an argument
> count error.
>
I think it’s reasonable to allow passing more arguments to a partial since
user-defined functions and closures allow this without error.
Whether or not the extra arguments are automatically forwarded to the function
wrapped by the partial is debatable.
Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
`$partial = foo(?, 42)`.
If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z` or
should the call error as providing too few arguments? Or perhaps should the
partial declaration should error, as it should have been `foo(?, 42, ?)` or
`foo(?, 42, ...?) so the partial provided all required arguments to foo.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Partial function application
On 25/04/2021 20:25, Larry Garfield wrote:
Discuss.
There has been intense discussion in R11 about how the ? token applies
to missing or variadic arguments.
The root of the concern is that in the current proposal, ? applies as
either a placeholder for a single replacement, or 0-or-more varadic
arguments, depending on its position and the number of arguments.
I and several others believe that this feature would be better served by
restricting ? to representing a single argument, and using ...? to
represent "anything else" including an empty set.
## To illustrate the scope for confusion:
foo(?) looks like it requires one argument, when in reality it could
accept none, 1, or a hundred.
foo(1, ?) looks like it also accepts one argument, but it could accept
0, or 100, depending on the function it is wrapping.
foo(?, 1) definitely requires at least one argument, but could accept
more depending on what it's wrapping.
## Suggestion
Based on discussions in R11 there seems to be broad agreement that ?
should represent a single argument, and ...? should represent everything
else (including no arguments).
Thus:
foo(...?) - Partial of foo with all the arguments copied over.
foo(?, 1, ..?) - 1 required, then 1 fixed, 0 or more others are copied over.
foo(1, ...?) - Fix the first parameter and copy over the rest.
This can be seen as a mirror to the ... operator that accepts a variable
number of arguments.
function foo($a, ...$b) { }
Equally it matches the syntax for unpacking into arguments:
$a = foo($a, ...$b);
Passing more arguments than the partial defines would result in an
argument count error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Add IntlDatePatternGenerator
Hi Internals, I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator. I will close it on 2021-05-28. For previous discussion see https://externals.io/message/113831 and https://externals.io/message/114124. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On Thu, May 13, 2021, at 3:30 PM, Sara Golemon wrote: > On Thu, May 13, 2021 at 2:31 PM Andreas Hennings > wrote: > > > 1. Serializing: > > But outside of the above cases it should be technically possible, or not? > > > > > I suspect that the limitations you cite make any kind of general > serializing both unreliable and impractical. I wouldn't plan on meaningful > serialization. Correct. A partial produces a Closure object like any other now, so it's as serializable as any other Closure object. That is to say, not at all. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Infrastructure help
Hi internals! If you can use some extra hands to work on PHP's infrastructure (maintenance, migrations, monitoring, ...) I would like to offer my help. I'm a sysadmin in my day job so this should be stuff that is close to my comfort zone. Who should I talk to or what platforms should I join? I would be happy to hear from you! Kind regards, Tom Van Looy
