Pipeline Operator (Stage 1)

[hzoo]

Champion: @littledan
Spec Repo: https://github.com/tc39/proposal-pipeline-operator
First presented at Sept 2017 meeting: https://github.com/tc39/agendas/blob/master/2017/09.md
Slides: https://docs.google.com/presentation/d/1qiWFzi5dkjuUVGcFXwypuQbEbZk-BV7unX0bYurcQsA/edit#slide=id.p
Related proposal: Partial Application https://github.com/rbuckton/proposal-partial-application by @rbuckton
Related proposal: Function Bind Operator https://github.com/tc39/proposal-bind-operator

Basic Example

Input

let result = "hello"
  |> doubleSay
  |> capitalize
  |> exclaim;
result //=> "Hello, hello!"

Output

let result = exclaim(capitalize(doubleSay("hello")));
result //=> "Hello, hello!"

Initial Implementation (would need updating to v7)

• Initial Spec PR by @littledan Add a specification tc39/proposal-pipeline-operator#51

Old/Alternative Implementations

• Old PR to Babel: New plugin for pipeline operator proposal babel#3159
• https://github.com/SuperPaintman/babel-plugin-transform-pipeline
• << and >>: https://github.com/michaelmitchell/babel-plugin-pipe-composition

cc @gilbert, @SuperPaintman

Implementation

• Parser PR: Pipeline Operator proposal babylon#742
• Transform PR: Pipeline operator babel#6335
• Feedback around relating Pipeline Operator, Function Bind, Partial Application

[nicolo-ribaudo]

There is also another Babylon implementation (https://github.com/airdwing/babylon), which could be already mergeable because the fork was updated one month ago.

[hzoo]

didn't know it was that simple ha - needs hasPlugin, tests, readme, etc though

[nicolo-ribaudo]

Oh right 😅

[hzoo]

Merged the parser PR

[hzoo]

Transform PR: babel/babel#6335, test at https://babeljs.io/repl/build/5099/

[hzoo]

Linking to Dan's syntax concern (not specced) tc39/proposal-pipeline-operator#60

[hzoo]

Some syntax used in the spec repo examples that doesn't parse currently: are these supposed to be?

class Comment extends Model |> Editable |> Sharable {}

[ljharb]

I would expect that to parse as long as Model |> Editable |> Sharable parses, since the RHS of extends is an expression.

[littledan]

@hzoo You are right, the explained does not match the spec. Sorry for this state of things. I hope to address it soon.

[littledan]

Address in the sense of adding more parens in the explainer; I don't have a clear idea of alternative syntax.

[littledan]

@js-choi @mAAdhaTTah Could you summarize the current plans here for future reference?

[js-choi]

@littledan I’ll write one.

Edit: Dang, beaten to it.

[mAAdhaTTah]

@littledan We're working in parallel on a configuration option for two proposals: F# Pipelines & Smart Pipelines. @js-choi is currently working on the babylon changes required to parse the Smart Pipelines, behind a smartPipelines plugin / flag. Once his is finished, I'm going to follow up with changes of my own behind a fsharpPipelines flag. All of that will be captured in babel/babel#7458

As part of this work, I'll be submitting a PR to the pipeline proposal itself to update the spec to remove any current handling of await, and update the parser to match the current spec, with await being an early error and fixing the current handling of unparen'd arrows. Depending on where we land in tc39/proposal-pipeline-operator#104, F# will either match this behavior or implement the new behavior.

Once the parser changes are complete, we'll then be updating the babel pipeline plugin with a configuration options for these proposals. I don't think we've specified what that flag is just yet, but the intention is to have three "modes": spec, fsharp, & smart, with spec matching whatever's accepted in the current spec.

I'll also eventually be writing up a spec & explainer for F# pipelines. The current spec & explainer for smart pipelines is here: https://github.com/js-choi/proposal-smart-pipelines

[danielo515]

Is this available to test on the REPL ? I can't get it to work

[mAAdhaTTah]

@danielo515 The minimal proposal is in babel right now, but the rest of what I explained is still in progress. Past 2 months have been busy for both JS Choi & me, so we haven't made as much progress as we'd like.

Also, the plan has changed from what was described above; we're going to add all those flags in a fork of babylon (now @babel/parser) and only merge back the version that advances to Stage 2. During that time, the various flags / configurations won't be in babel proper.

[nicolo-ribaudo]

I think that we could merge them even before stage 2, since now Babylon supports plugin options

[mAAdhaTTah]

Couple updates I want to drop in here:

1. Initially, we were going to make the changes in a babylon fork, but as @nicolo-ribaudo helpfully points out, we have options in the parser now, so we can use a single flag for the pipeline operator with options, which will be cleaner than multiple flags.
2. Suggested by @ljharb, the default for the pipeline operator will be "Throw an error unless you specified which proposal you want," which enables us to go from "no defaults allowed" -> "default is accepted spec" whenever pipeline settles on a particular proposal.

I'll be working on point 2 ASAP, as that needs to land before babel 7 leaves beta.

[zfrisch]

I was curious what was up with the pipeline operator in babel? Every plugin I've tried hasn't worked, and even in the repl with the specified package it won't compile.

I'm excited by this proposal and I recently wrote an article about the pipeline operator (Medium: JS Pipeline Operator Article) and created my own pipeline operator playground: (CodePen: PipeLine Operator Playground).

I was hoping that by now babel would have an official working plugin available for it, but nothing seems to be checking out.

[mAAdhaTTah]

@zfrisch There's a Project on babel with the current status: https://github.com/babel/babel/projects/9 - we have several proposals we're trying to land, so a lot going on before we're done.

[js-choi]

See also @mAAdhaTTah’s article “What’s Happening with the Pipeline Proposal?”. We’re working on implementing a bunch of preliminary proposals, each with their own trade-offs, so that TC39 and others can try them out, hands on.

[gajus]

What is the current stage of this proposal?

CC facebook/flow#5443

[chicoxyzzy]

Stage 1, last presented in March 2018

[goodmind]

Is this minimal or F#?

[ljharb]

@goodmind none has been selected. It's not until stage 2 that the shape of the solution is mostly settled.

[jazithedev]

@ljharb When will be the "stage 2"?

[ljharb]

@ktrzos no idea - the champions of the proposal would have to decide its ready, and add it to a meeting agenda in advance of the deadline for doing so, and then the committee would have to agree. The next such opportunity is at the end of January, but it remains up to the proposal champions to decide when that next step is warranted.