Re: Re: Explainer/Spec: Smart pipelines
@Naveen: > If generator composition isn't directly supported somehow, then I'd have to > say I personally find the function composition proposal more compelling on > its own, even in the absence of a pipeline operator. That’s all right, Naveen; thank you for reading the explainer and/or spec anyway. You may find the smart pipelines—or pipelines in general—still useful for all its other use cases, including method extraction, method application, function application, and partial application. And, importantly, the smart pipeline proposal does not preclude the future addition of a composition operator that can compose generators. It is just out of the current scope. I myself am trying to think of ways that smart pipelines might be eventually extended to support generator composition. As for TheNavigateur’s proposal in specifics, though—I will say that I think its approach to even generators has disadvantages, though I need to think more about someone might best address them. Perhaps most seriously, generators are not intended by the designers to be distinguishable from functions that return iterators (I think I can find a citation from Domenic Denicola for that), just like how async functions are not intended to be distinguishable from promise-returning functions (I’m almost certain can find a citation from Denicola for that). But in addition, the problem of plural/iterator/functor/whatever-type composition is not as easy as simply as treating generators and async generators with special behavior. There are so many types of plural or container objects—not only generators and async generators, but also maybes, streams, observables, and the iterators themselves. TheNavigateur’s approach does not address these, despite their being reasonable similar cases. And there are also many ways to compose them. TheNavigateur’s approach only addresses composition with mapping. But I would want a pipeline approach that addresses plural things to also be able to compose functions with flattened mapping, filtering, taking/dropping, partitioning, reduction, and so many other types of transformations. There is an alternative proposal for function composition, https://github.com/isiahmeadows/function-composition-proposal/blob/master/README.md, which tries another approach: having a well-known symbol Symbol.lift, which is used. But I’m not satisfied with that proposal either. I want to see if there is a different approach to try, one that may integrate with smart pipelines. Something like `generateRandomNumbers() |>> map f |>> filter g |>> take 5`…but I don’t yet know precisely how. But smart pipelines might be extendable to handle them. Either way, it can be dealt with later. There are many other benefits, as hopefully you can see from the real-world code examples. But we’ll see, once the Babel plugins are written and TC39 takes a look. Thanks for reading the explainer and/or spec. Warm re-gards, J. S. Choi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Explainer/Spec: Smart pipelines
lls. All other cases are intended to use topic style, which hopefully is still terse, yet explicit enough to avoid ambiguity. In fact, several examples in the readme are drawn from Ramda’s cookbook, several of which, if I recall correctly, involve autocurrying functions ([Ramda examples, part 1][] and [Ramda examples, part 2][]). Your example using Lodash/FP, `['a', null, 'c'] |> fs.filter(Boolean)`, is expressible using `['a', null, 'c'] |> fs.filter(Boolean)(#)`. The latter is a valid topic-style pipeline. In general, `x |> f(a, b)` is visually ambiguous between four reasonable interpretations:\ `x |> f(a, b, #)`, `x |> f(a, #, b)`, `x |> f(#, a, b)`, and `x |> f(a, b)(#)`. The early error forces the writer to specify which of the four reasonable interpretations they mean, also reducing the parsing burden on the human reader. [Ramda examples, part 1]: https://github.com/js-choi/proposal-smart-pipelines/blob/master/readme.md#ramda-core-proposal--additional-feature-bppf [Ramda examples, part 2]: https://github.com/js-choi/proposal-smart-pipelines/blob/master/readme.md#ramda-core-proposal--additional-features-bppfnp *** > > [me] optionally preceded by `new` or `await` > > [Peter] This seems very arbitrary and not forwards-compatible. My apologies again – I am also confused by what you mean here by forwards-compatible. What is there for bare style to be forward compatible with? New prefix operators? If a new operator is commonly used before unary function calls, then they could be added to bare style’s syntax later, but in the meantime topic style can handle them, as well as anything else, simply by appending `(#)`. Bare style is a special syntax, with special evaluation semantics, optimized for one common use case: unary functions. The `new` and `await` tokens are just flags for bare style because unary constructor calls and awaited unary async-function calls are also quite common, as my review of real-world codebases in [Motivation][] shows. But in general, I expect topic style to be used more often, and topic style itself is very terse. In fact, the `new` and `await` flags in bare style were originally not there. The only reason why I added them in the first place was because, during that [review of real-world code][Motivation], I found that unary constructor calls and awaited unary async-function calls are very common. I am still considering removing them from the Core Proposal, into their own separate Additional Features, so that their tradeoffs may be independently considered. [Motivation]: https://github.com/js-choi/proposal-smart-pipelines/blob/master/readme.md#motivation *** > By only allowing identifiers, you're requiring people to create unnecessary > intermittent variables. I propose that you allow any expression on the > right-hand side of the pipe operator, and decide whether it's in topic style > or bare style based on the inclusion of the lexical topic token. Your > argument that making it very restrictive reduced cognitive burden doesn't > make sense to me at all, as remembering what is and isn't allowed is more > difficult than just remembering "if it doesn't have the token, it will call > the function specified by the expression with the argument of the result of > the previous step in the pipeline". Hopefully, the quotation I pasted from the [syntactic locality][] section from above is an adequate response to this paragraph. Bare style’s rules are simple: “”. The rules are simpler than humans and computers having to search a [long pipeline expression][garden-path syntax], such as `value |> compose(f, g, h, i, j, k, #, l, m, n, o)` or `value |> compose(x['hello'][symbol].propertyA.key(#).propertyB.propertyC, anotherFunction)`, for the absence or presence of a single topic reference `#`. In many reasonable cases, parsing would be considerably more complicated, for humans and computers alike. [syntactic locality]: https://github.com/js-choi/proposal-smart-pipelines/blob/master/readme.md#syntactic-locality [garden-path syntax]: https://en.wikipedia.org/wiki/Garden_path_sentence *** Thanks again for the reply. Your `x['hello']`-method example and your Lodash/FP example are both already addressed by the current smart-pipelines proposal. I hope these explanations clarify your understanding of the current proposal. I’ll have only intermittent free time in the next few days, but in the meantime James DiGioia and I will be working on the Babel plugin for both smart pipelines and F-sharp Style Only pipelines. I’ll try to reply to any reply here when I can. Warm regards, J. S. Choi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Explainer/Spec: Smart pipelines
g in cooperation with James DiGioia, who is also working on a proposal for Proposal 1: F-sharp Style Only (https://github.com/tc39/proposal-pipeline-operator/wiki#proposal-1-f-sharp-style-only). We will see what comes of all this in the future. Warm regards, J. S. Choi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Explainer/Spec: Smart pipelines
ESDiscuss.org stripped much of the formatting from my original message. To give the links in plain text: Readme explainer: https://github.com/js-choi/proposal-smart-pipelines/ Formal spec: https://jschoi.org/18/es-smart-pipelines/spec Issue tracker (please specify Proposal 4 in new issues): https://github.com/tc39/proposal-pipeline-operator/issues?utf8=✓=sort%3Aupdated-desc+ List of all current pipeline proposals: https://github.com/tc39/proposal-pipeline-operator/wiki Warm regards, J. S. Choi > On Mar 9, 2018, at 3:04 PM, J. S. Choi <js_c...@icloud.com> wrote: > > I’d like to ask for feedback/criticism on a detailed explainer and > specification for Smart Pipelines plus several possible extensions. > > Readme explainer: https://github.com/js-choi/proposal-smart-pipelines/ > Formal spec: https://jschoi.org/18/es-smart-pipelines/spec. > There is a simple “actual” Core Proposal at Stage 0 championed by Daniel > Ehrenberg, plus several optional Additional Features that extend the Core > Proposal and address several other use cases. Daniel will present the Core > Proposal at the next TC39 meeting, in several weeks at London. > > The Core Proposal is a variant of the first pipeline-operator proposal also > championed by Ehrenberg; this variant is listed as Proposal 4: Smart Mix in > the pipe-proposal wiki. The variant resulted from previous discussions in the > previous pipeline-operator proposal, discussions which culminated in an > invitation by Ehrenberg to try writing a specification draft. A prototype > Babel plugin is also being written. > > I should stress that the Additional Features are separate, optional and > mutually independent add-on proposals. The Additional Features show the > potential of simply extending the Core Proposal to handle other use cases > (such as composition, partial application, and method extraction). And I’ve > attempted to keep the Core Proposal forward compatible with all of the > additional features. > > If you have any questions after reading the explainer and specification, > please feel free to file an issue on the GitHub issue tracker. When you file > an issue, please note in it that you are talking specifically about“Proposal > 4: Smart Mix”. Or leave a comment here. > > Warm regards, J. S. Choi > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Explainer/Spec: Smart pipelines
I’d like to ask for feedback/criticism on a detailed explainer and specification for Smart Pipelines plus several possible extensions. Readme explainer: https://github.com/js-choi/proposal-smart-pipelines/ Formal spec: https://jschoi.org/18/es-smart-pipelines/spec. There is a simple “actual” Core Proposal at Stage 0 championed by Daniel Ehrenberg, plus several optional Additional Features that extend the Core Proposal and address several other use cases. Daniel will present the Core Proposal at the next TC39 meeting, in several weeks at London. The Core Proposal is a variant of the first pipeline-operator proposal also championed by Ehrenberg; this variant is listed as Proposal 4: Smart Mix in the pipe-proposal wiki. The variant resulted from previous discussions in the previous pipeline-operator proposal, discussions which culminated in an invitation by Ehrenberg to try writing a specification draft. A prototype Babel plugin is also being written. I should stress that the Additional Features are separate, optional and mutually independent add-on proposals. The Additional Features show the potential of simply extending the Core Proposal to handle other use cases (such as composition, partial application, and method extraction). And I’ve attempted to keep the Core Proposal forward compatible with all of the additional features. If you have any questions after reading the explainer and specification, please feel free to file an issue on the GitHub issue tracker. When you file an issue, please note in it that you are talking specifically about“Proposal 4: Smart Mix”. Or leave a comment here. Warm regards, J. S. Choi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Function composition vs pipeline
See also recent discussions in these GitHub issues that touch on composition: https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc. Look particularly at the issues that were created after 2018-01-31 – when Gilbert/Mindeavor split the proposal into four competing proposals – since those issues reflect the current state of the art. To see those four competing proposals, look at the pipeline operator’s wiki, which has a list of the four proposals (https://github.com/tc39/proposal-pipeline-operator/wiki). In particular, Naveem, you may be interested in https://github.com/tc39/proposal-pipeline-operator/issues/93, which discusses the intersection of terse function application and terse function composition.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
