Reviving Partial Application

[codehag]

Hi, I would be interesting in helping champion and move this proposal forward.

[Pokute]

I'm also willing to help in this effort from the code side. I've made a branch of TypeScript with partial application support https://github.com/Pokute/TypeScript/tree/partial-application

[aadamsx]

This is great guys, I'd email Ron Buckton and ask him what can be done to move this forward.

Good luck!

[rbuckton]

The biggest blocker to partial application has been proposals such as the smart pipelines proposal, which is attempting to do something similar with wildly different syntax. This proposal initially was intended to dovetail into the (F#-style) pipelines proposal as a way to resolve the first-arg (lodash-style) vs. last-arg (Ramda-style) debate.

I've essentially put this proposal on hold until the pipeline proposal has settled on a direction.

[Pokute]

While I've been under the impression that while (F#-style) pipeline operator proposal has been the main end goal of partial application, this can still be advanced as a separate proposal and is even useful as a standalone feature.

I consider this proposal having significant merit as-is and thus stage 2 advancement should be aimed for, regardless of the pipeline proposal. The advancement of this proposal will surely tip the scales on pipeline implementation towards F#-style, but the pipeline operator proposal seems to have stalled already. If there is active work ongoing for the pipeline operator proposal then I would indeed wait for it.

[mAAdhaTTah]

this can still be advanced as a separate proposal and is even useful as a standalone feature.

That assumes F# as the pipeline proposal. Smart pipelines have a placeholder feature as well and would effectively kill partial application as a standalone feature. That placeholder feature can be expanded with some of Smart pipeline's follow-on proposals to encompass what's covered by partial application, but that's the reason the two features remain somewhat dependent upon one another.

[codehag]

@rbuckton hi, some context behind my desire to revive this proposal:

Last year I ran a large scale survey to understand which of the two proposals, F# or smart pipelines, works better for developers. While most developers preferred the smart pipeline syntax, it was slightly more error prone. What is more, after fully categorizing and tagging the comments on the two proposals, the second most cited comment was around consistency -- the smart pipeline is inconsistent with regards to existing javascript. To paraphrase, while the placeholder functionality in the smart pipeline is nice, it would be nicer to have it applied to the entire language. In fact, some participants said that they would prefer just to have the partial application even without the pipeline proposal.

This is what brought me back to this proposal and why I made this issue. I think this needs to be revived and is the right direction to resolve the pipeline question. Further, this may be the more important proposal of the two.

I know there were some questions related to potential footguns with this proposal. These can be identified and addressed through a similar experiment as the one that was run with pipeline. For presenting this to the committee, I hope to do this with a ready experiment design. Don't worry, it won't take as long to get the results back this time as I have help this time!

[noppa]

@mAAdhaTTah

Smart pipelines have a placeholder feature as well and would effectively kill partial application as a standalone feature.

That's probably true, but also kind of sad because—at least without several of the suggested future extensions—Smart pipeline topics lack several useful features that the partial application operator has.

Partial application can be used outside of pipelines, so you can do

values.map(roundToPrecision(?, 2))

Even with pipelines, I have found that it's often needed to have nested lambdas in RHS when LHS is a list, for example. Partial application is still useful when that's the case

values
  |> uniqueBy(?, roundToPrecision(?, 2))

Topic placeholders, not so much.
Being able to leave multiple arguments open could also be useful

const readFileText = require('fs').readFile(?, ?, 'utf8')

IIRC some committee members expressed in a comment somewhere that they found bind-operator's method extraction feature very important. Well, I don't know if it has been proposed here (and admittedly I haven't given this thought much time so it might be that it wouldn't make sense) but if the partial application would also have property foo.bar(?) === foo.bar(?) then we'd pretty much have that use case solved too, right?

class MyCustomElement extends HTMLElement {
  onResize(event) {
    ...
  }
  connectedCallback() {
    window.addEventListener('resize', this.onResize(?))
  }
  disconnectedCallback() {
    window.removeEventListener('resize', this.onResize(?))
  }
}

I know some of these use cases are covered in the suggested additional features for Smart, but since those are not even part of the official proposal at the moment, it's hard to evaluate if these use cases would or even could be covered if we go with Smart.

[Pokute]

Made the Partial Application TypeScript draft PR

It does need quite a bit of work still.

Playground Link

To test it in your project, add following to your package.json:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/71368/artifacts?artifactName=tgz&fileId=66B315F01746D1BB7A072158A87E42DB63D7306711F0EE0AEF20182FF008484802&fileName=/typescript-3.9.0-insiders.20200415.tgz"
    }
}

and then run npm install.

[codehag]

@rbuckton would you be alright with me putting this on the agenda for the upcoming meeting?

[rbuckton]

@codehag That would be fine with me. I'm more than happy to add you as a co-champion as well.

[treybrisbane]

@rbuckton A partial application operator would be hugely useful to me, irrespective of a pipeline operator. The feature is generally useful enough in isolation, IMO.

Have you considered just pushing ahead with the proposal on that basis?

Given that there seems to be much less contention around what you have here, it doesn't make much sense to me to block this on the pipeline operator proposal. Hell, if partial application were to land, it may even help break the deadlock around the pipeline operator discussions.

[aadamsx]

Why does partial application have to be contengent on pipes? This feature can stand on its own @rbuckton. Why not move this forward on the July TC39 meeting?

[rbuckton]

Why does partial application have to be contengent on pipes? This feature can stand on its own @rbuckton. Why not move this forward on the July TC39 meeting?

Partial Application is no longer contingent on the pipeline proposal, and has recently introduced changes in syntax (#49) to attempt to resolve existing "garden path" concerns. I plan to propose advancement to Stage 2 at the October, 2021 meeting.

@codehag: Please let me know if you are still interested in cooperating on this proposal.