Remove references to pipelines

[mmkal]

This feature is being held up by the pipeline operator, when it should be the other way around. This proposal in no way depends on the pipeline operator. Maybe this could be moved forward, as suggested in https://github.com/tc39/proposal-partial-application/issues/36, by getting rid of the pipeline examples and focusing on the many, many other use cases? That way, this proposal can be evaluated on its own merits. For example, we can just use an array in the "player scores" example in the readme.

const addOne = add(1, ?); // apply from the left
addOne(2); // 3

const addTen = add(?, 10); // apply from the right
addTen(2); // 12

// with pipeline
let newScores = player.scores
  .map(add(7, ?))
  .map(clamp(0, 100, ?)); // shallow stack, the pipe to `clamp` is the same frame as the pipe to `add`.

// partial template strings
const Diagnostics = {
  unexpected_token: `Unexpected token: ${?}`,
  name_not_found: `'${?}' not found.`
};
Diagnostics.name_not_found("foo");

It's understandable that Hack and F# are at odds in the other proposal, since they're basically incompatible. But that really has nothing to do with partial application. It would be bizarre if by Hack "winning" we lost the ability to use partial application outside of pipelines too.

@rbuckton would you be open to a PR removing pipelines from the example here? Then this can be established more clearly as a nice-to-have dependency of F# pipelines, and not much to do with Hack pipelines at all.

[mAAdhaTTah]

Removing the examples wouldn't reduce the hostage situation–the presence of a placeholder in Hack at all puts the two proposals in conflict, because the committee won't advance two solutions for placeholders into the language.

[mmkal]

It wouldn't eliminate the stand-off. But it would make it clearer that:

1. Partial application is useful as a standalone proposal.
2. As a result, pipelines should accomodate partial application, more than the other way around.

Which would hopefully make the stand-off easier to resolve.

[theScottyJam]

There are four possible ways for the pipeline proposal to move forwards:

• F# pipes
• F# pipes + partial application
• hack pipes
• no pipes + partial application

If partial application goes in, then we've immediately ruled out hack pipes as an option. Your conclusion:

As a result, pipelines should accomodate partial application, more than the other way around.

seems to already be ruling out hack pipes as an option (if we decide that partial application will go in, and pipeline must accommodate it, then hack pipes will not be an option).

It's true that partial application has value by itself, but it's not going to go into the language until we've decided which of those four paths laid out above we want to take. The two proposals must be intertwined, neither proposal can go in until the overall path has been decided. Once a path has been decided, then these proposals can evolve independently and go in at their own time, when they're ready.

[rbuckton]

In #49 I've removed some references to pipelines and have commented out others that I intend to rewrite. There is still a use for partial application in conjunction with Hack-style pipelines, it just isn't the same use that it might have had with F#-style pipelines:

const add = (x, y) => x + y;
const greaterThan = (x, y) => x > y;

// using Hack-style pipes
elements
  |> map(^, add~(?, 1))
  |> filter(^, greaterThan~(?, 5));

[rbuckton]

I've added an update to #49 that shows partial application in combination with Hack-style pipelines.