The "Pipeline" Operator - Making multiple function calls look great

Caitlin Potter caitpotter88 at gmail.com
Sun Dec 6 22:56:52 UTC 2015


>On Dec 6, 2015, at 4:51 PM, Gilbert B Garza <gilbertbgarza at gmail.com> wrote:
>
>Confusing and horrible are subjective, but I do agree that it's not as nice as the original proposal.
>Although I prefer the original, it's also important to discuss objections that people bring up, as well as
>the alternatives that might solve said objections :)

Even with the original solution, it just creates a new (and less obvious) way of writing something that is already possible in the language,
and easier to understand. There is a narrow scope of times where it even makes sense to use the original (or enhanced) version of the
proposal, and this requires authors to be vigilante about knowing when to pick one form over the other. It also requires code reviewers
to be vigilante in knowing when to say “know, this is a bad idea, stop”.

It doesn’t look like there is any redeeming quality about this change, it doesn’t introduce convenience, and does introduce new pain points
for authors. Anything involving “placeholders arguments” is especially bad because it introduces an extra thing to reason about, but the issue
with introducing a new syntax to pick and be aware of for limited gains is also problematic, growing the language and increasing complexity
for a less than substantial reason.

The bind operator may at least have the benefit of providing some out of the box support for classic FP style, so it’s got that going for it (but really,
the language doesn’t need three distinct syntaxes/idioms for this pattern, the complexity budget is already running thin)

> 
> Gilbert
> 
> On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter <caitpotter88 at gmail.com <mailto:caitpotter88 at gmail.com>> wrote:
> These examples only make this language extension look like a confusing and horrible thing. How is this an improvement, in any way?
> 
>> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza <gilbertbgarza at gmail.com <mailto:gilbertbgarza at gmail.com>> wrote:
>> 
>> Status update: The JS community has shown [lots of excitement](https://twitter.com/markdalgleish/status/673581814028492800 <https://twitter.com/markdalgleish/status/673581814028492800>) for the idea of this proposal, but the syntax is still being debated. I outlined two alternatives [in this GitHub issue](https://github.com/mindeavor/es-pipeline-operator/issues/4 <https://github.com/mindeavor/es-pipeline-operator/issues/4>), one of which I will post here since it is my current favorite:
>> 
>> ## Placeholder Arguments
>> 
>> The alternative is to have a new syntax for "placeholder arguments" – basically, slots waiting to be filled by the next function call. For example:
>> 
>> ```js
>> //
>> // Placeholder style
>> //
>> run("hello") |> withThis(10, #);
>> // is equivalent to
>> withThis( 10, run("hello") );
>> 
>> //
>> // More complicated example
>> //
>> run("hello") |> withThis(10, #) |> andThis(#, 20);
>> // is equivalent to
>> andThis( withThis( 10, run("hello") ), 20 );
>> ```
>> 
>> ### Pros / Cons
>> 
>> - [pro] Very explicit (no surprises)
>> - [pro] Less function calls
>> - [pro] Compatible with even more of the JavaScript ecosystem
>> - [con] Requires more new syntax
>> - [con] Usage of the hash operator (#) would probably be hard to define outside coupled use with pipeline operator (this problem could be avoided by simply making it illegal)
>> 
>> 
>> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza <gilbertbgarza at gmail.com <mailto:gilbertbgarza at gmail.com>> wrote:
>> Ah, sorry for being unclear. You're right, in the case of manual currying, the closure can not and should not be optimized away.
>> 
>> I was talking about the case where you have arrow function literals. For example:
>> 
>> ```js
>> var bounded = 750
>>     |> s => Math.max(100, s)
>>     |> s => Math.min(0, s);
>> ```
>> 
>> I imagine if the compiler sees arrow functions used in this specific manner, it could automatically optimize to the following:
>> 
>> ```js
>> var bounded = Math.min( 0, Math.max(100, 750) )
>> ```
>> 
>> Semantically, they are equivalent; no closures nor scopes were effectively used in the intermediary arrow functions.
>> 
>> 
>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>> wrote:
>> Not with your semantics. It has to generate a closure each time, because of the possibility it can't be used elsewhere. That's impossible to know ahead of time if the variable is ever used outside of its closure or as a value. In the case below, it should only log thrice. Otherwise, it's unexpected behavior.
>> 
>> ```js
>> function add(x) {
>>   console.log("Hit!");
>>   return y => x + y;
>> }
>> 
>> let inc = add(1);
>> 
>> 1 |> inc |> inc |> add(2) |> add(3);
>> 
>> // Hit!
>> // Hit!
>> // Hit!
>> ```
>> 
>> 
>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza <gilbertbgarza at gmail.com <mailto:gilbertbgarza at gmail.com>> wrote:
>> 
>> Normally yes, but since the pipeline operator is a pure function, I think it's possible for the compiler to optimize away the intermediate arrow functions. I mention this in the "Functions with Multiple Arguments" section https <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>:// <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>github.com <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>/ <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>mindeavor <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>/ <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>ES7-pipeline-operator#functions <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>-with-multiple-arguments <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>> 
>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>> wrote:
>> 
>> Inline
>> 
>> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith <zenparsing at gmail.com <mailto:zenparsing at gmail.com>> wrote:
>> >> - I don't like the requirement to use the keyword `this` to compose
>> >> functions. JS already has many features to support the keyword `this`:
>> >> prototypes, method invocations, function binding, arrow functions, and
>> >> probably others. I prefer a feature that assists the other side of the
>> >> spectrum.
>> >
>> >
>> > Yep - a well documented critique.  It depends on your point of view, I
>> > think.  If you view these things as "extension methods", then using `this`
>> > makes more sense.
>> >
>> >> - The fact that there are new semantics to what looks like a normal
>> >> function call (e.g. `->map(...)`) doesn't set well with me. You could argue
>> >> that it's something to get used to. Even in that case, I would expect the
>> >> first argument I give to `map` to stay the first argument.
>> >
>> >
>> > This is a reasonable objection, I think.
>> 
>> Not to mention it's still a point of contention:
>> https <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>:// <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>github.com <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>/ <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>zenparsing <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>/ <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>es-function-bind <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>/issues/26#issuecomment-154130932 <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>> (from here, down)
>> 
>> >
>> >> With the pipeline operator, partial application is left to the developer.
>> >> They can choose to use arrow functions, or to curry their functions. I think
>> >> this is the best option since it keeps things simple (no new semantics), and
>> >> remains readable – see the "Function with Multiple Arguments" section in the
>> >> GitHub link https <https://github.com/mindeavor/ES7-pipeline-operator>:// <https://github.com/mindeavor/ES7-pipeline-operator>github.com <https://github.com/mindeavor/ES7-pipeline-operator>/ <https://github.com/mindeavor/ES7-pipeline-operator>mindeavor <https://github.com/mindeavor/ES7-pipeline-operator>/ <https://github.com/mindeavor/ES7-pipeline-operator>ES7-pipeline-operator <https://github.com/mindeavor/ES7-pipeline-operator>
>> >
>> >
>> > I agree that your proposal wins points for simplicity (both semantic and
>> > syntactic), but having to create an arrow function to pass more than one
>> > argument feels a bit awkward and seems to defeat some of the readability
>> > benefit.
>> 
>> Not to mention it would be pretty slow. That's going to be creating a
>> closure each call. Engines still struggle with making closures fast.
>> It's non-trivial at runtime to create a closure that's performant.
>> 
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> > https <https://mail.mozilla.org/listinfo/es-discuss>:// <https://mail.mozilla.org/listinfo/es-discuss>mail.mozilla.org <https://mail.mozilla.org/listinfo/es-discuss>/ <https://mail.mozilla.org/listinfo/es-discuss>listinfo <https://mail.mozilla.org/listinfo/es-discuss>/ <https://mail.mozilla.org/listinfo/es-discuss>es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>> >
>> 
>> 
>> --
>> Isiah Meadows
>> 
>> 
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151206/f54e5f49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151206/f54e5f49/attachment-0001.sig>


More information about the es-discuss mailing list