New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipeline Operator (Stage 1) #29

Open
hzoo opened this Issue Sep 26, 2017 · 17 comments

Comments

Projects
None yet
7 participants
@hzoo
Member

hzoo commented Sep 26, 2017

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)

Old/Alternative Implementations

cc @gilbert, @SuperPaintman

Implementation

@hzoo hzoo added the Proposal Issue label Sep 26, 2017

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Sep 26, 2017

Member

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

Member

nicolo-ribaudo commented Sep 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Sep 26, 2017

Member

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

Member

hzoo commented Sep 26, 2017

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

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Sep 26, 2017

Member

Oh right 😅

Member

nicolo-ribaudo commented Sep 26, 2017

Oh right 😅

This was referenced Sep 27, 2017

@hzoo hzoo referenced this issue Sep 28, 2017

Merged

Pipeline Operator proposal #742

4 of 4 tasks complete
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Sep 29, 2017

Member

Merged the parser PR

Member

hzoo commented Sep 29, 2017

Merged the parser PR

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo
Member

hzoo commented Sep 30, 2017

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Sep 30, 2017

Member

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

Member

hzoo commented Sep 30, 2017

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

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Oct 2, 2017

Member

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

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

Member

hzoo commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Oct 2, 2017

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

ljharb commented Oct 2, 2017

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

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Oct 11, 2017

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

littledan commented Oct 11, 2017

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

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Oct 11, 2017

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

littledan commented Oct 11, 2017

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

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Mar 13, 2018

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

littledan commented Mar 13, 2018

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

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Mar 13, 2018

@littledan I’ll write one.

Edit: Dang, beaten to it.

js-choi commented Mar 13, 2018

@littledan I’ll write one.

Edit: Dang, beaten to it.

@mAAdhaTTah

This comment has been minimized.

Show comment
Hide comment
@mAAdhaTTah

mAAdhaTTah Mar 13, 2018

@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

mAAdhaTTah commented Mar 13, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@danielo515

danielo515 Jun 4, 2018

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

danielo515 commented Jun 4, 2018

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

@mAAdhaTTah

This comment has been minimized.

Show comment
Hide comment
@mAAdhaTTah

mAAdhaTTah Jun 4, 2018

@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.

mAAdhaTTah commented Jun 4, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Jun 4, 2018

Member

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

Member

nicolo-ribaudo commented Jun 4, 2018

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

@mAAdhaTTah

This comment has been minimized.

Show comment
Hide comment
@mAAdhaTTah

mAAdhaTTah Jun 4, 2018

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.

mAAdhaTTah commented Jun 4, 2018

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.

@mAAdhaTTah mAAdhaTTah referenced this issue Jun 19, 2018

Merged

Require proposal flag for pipeline plugin #8196

2 of 2 tasks complete

@vjpr vjpr referenced this issue Jul 11, 2018

Open

Tooling implementation status #123

0 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment