On Mon, May 17, 2021, 19:53 Guilliam Xavier <guilliam.xav...@gmail.com>
wrote:
>
>
> On Mon, May 17, 2021 at 5:47 PM Alexandru Pătrănescu <dreal...@gmail.com>
> wrote:
>
>>
>> On Mon, May 17, 2021 at 6:36 PM Guilliam Xavier <
>> guilliam.xav...@gmail.com> wrote:
>>
>>> On Mon, May 17, 2021 at 5:01 PM Levi Morrison <
>>> levi.morri...@datadoghq.com>
>>> wrote:
>>>
>>> > Joe Watkins has successfully worked out some bugs that also enable
>>> > more powerful behavior. Thanks to Nikita and any others who worked
>>> > with Joe on fixing these issues and reviewing the PR.
>>> >
>>> > The short of it is that re-ordering parameters when using named
>>> > placeholders is now technically possible. We will send an update when
>>> > the RFC and implementation are ready for re-review.
>>> >
>>>
>>> That's great news!
>>>
>>> By the way, I forgot to add that another syntax might also be clearer
>>> when
>>> binding a value to a named parameter, e.g.:
>>>
>>> ```
>>> function f($a, $b, $c, $d, $e) {/*...*/}
>>>
>>> /* We want to bind value 4 to param "d" */
>>>
>>> // with current syntax:
>>> $p = f(?, d: 4); /* or f(?, ?, ?, 4) */
>>>
>>> // with another hypothetical syntax:
>>> $p = *f(d: 4);
>>> ```
>>>
>>> Anyway, looking forward to your update =)
>>>
>>> Thanks,
>>>
>>> --
>>> Guilliam Xavier
>>>
>>
>> Hey Guilliam,
>>
>> adding a special character like * or ? before the function name is
>> not going to work.
>> It might look good for *f() but it has the same issues as casting.
>>
>> You should be able to have with the current version a code like
>> $actionGenerator->getDriveAction()('home', ?)
>> You can't really put the * or ? before the function name here.
>>
>> Maybe having it just before the parenthesis would work.
>>
>> Regards,
>> Alex
>>
>>
>>
>>
> Hey Alex,
>
> I was thinking of a (special) new unary [prefix] operator (e.g. `*` which
> currently only exists as binary) with a higher precedence than `()` (if
> that makes sense), which indeed means that e.g. `*f(1)(2)` would be like
> current `f(1, ?)(2)`, and `f(1)(2, ?)` would require wrapping as
> `*(f(1))(2)`.
> A lower precedence would require wrapping as `(*f)(1)` for the simple case
> (i.e. most of the time), which moreover would probably be problematic if
> you have both a `function f` and a `const f`.
>
> Just before the affected `(` might also work indeed, but with another
> symbol, as `f(1)*(2)` [and `f*(1)`] already means `f(1) * 2` [and `f *
> 1`]. Maybe `!`, `@` or `~` would be unambiguous at that position?
>
> (For both, there's also the possibility of choosing not a symbol but a
> keyword...)
>
> Alternatively, `f(..., d: 4)` or probably rather `f(d: 4, ...)` would
> arguably still be clearer than the current `f(?, d: 4)`, but still wouldn't
> really solve the "weirdness" of `noParam(...)` and `threeParams(1, 2, 3,
> ...)`.
>
> Sorry, I didn't intend to diverge so much. The gist is that I (too) don't
> like the current "duality" of `?`.
>
Actually, the current form is not very troublesome to me.
In terms of partial function application, it is fine and it serves the
purpose good enough while having a simple form.
The issue is that in recent discussions, also considering that parameter
re-ordering issue is done, it appears that we can use it also for other use
cases like simple pass-through adaptors between two interfaces.
And because of that, I would like to have also a partial closure where the
extra parameters are not passed further. And that is currently not
possible. Whether this feature is considered out-of-scope for partials,
that's for RFC authors to decide.
Cheers,
> Alex
>
