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

Gilbert B Garza gilbertbgarza at gmail.com
Sun Dec 13 04:43:00 UTC 2015


Alican, I am one to find brainstorming useful. I appreciate your feedback
(you make good points about await), but your tone might be taken as not
constructive.

I think you may be misunderstanding how the PO works. Specifically your
example here:

    // Have opFunc() with 0 parameters
    citizen |> opFunc;

That would be equivalent to `opFunc(citizen)`, which has one parameter.

To be clear, I don't think the PO conflicts with the bind operator. The
undeniable fact is that there are going to be functions that receive their
subject as a parameter, and – far fewer, I might add – functions that
receive their subject as the keyword `this`. Both are valid and useful
approaches, and I don't see them as conflicting with one another.

As mentioned in many other discussions, dealing with functions that take
multiple parameters is actually a separate issue – partial application.
Even so, functional programmers find good ways around the lack of built-in
partial application in JavaScript:

```js
let add = (x, y) => x + y;
let addCurried = x => y => x + y;

// "papp" stands for "partial application"
Function.prototype.papp = ...;

var result = 10
  |> add.papp(20)
  |> addCurried(30)
;
result //=> 60
```

In fact, if `papp` were built into the language, it would be simple for
compilers to optimize away an extra function call.

But I digress. My main point is that support for partial application is a
separate issue. The fact that the pipeline operator works without it is a
good thing (at least, as I see it).


On Sat, Dec 12, 2015 at 8:49 PM, Alican Çubukçuoğlu <
alicancubukcuoglu at gmail.com> wrote:

> This is a terrible example. It looks a lot better with what's already
> available:
> ```javascript
> async function runTask () {
>   const file = await fs.readFile('./index.txt');
>
>   const all = await* file
>     .split('\n')
>     .map(fs.readFile);
>
>   console.log(all.join('\n'));
> }
> ```
>
> Also how do you explain this feature to a newbie? This operator is
> supposed to call the function at the RHS with the value at the LHS and now
> it also has a special case when there is `await` at the RHS. How more
> complicated will this proposal get for the sake of making it look useful?
>
> This proposal's aim should basically be turning this:
> ```javascript
> myFunc(myVar);
> ```
> into this:
> ```javascript
> myVar |> myFunc;
> ```
>
> If it is not useful by just doing that then it should simply be rejected.
>
> ---
>
> About the usefulness of this proposal, this one conflicts with the
> function bind syntax and assuming FBS is all rainbows and unicorns and
> everyone should use it, then this proposal makes no sense since the
> original example should be written like this (and it's already good enough):
> ```javascript
> function doubleSay () {
>   return this + ', ' + this;
> }
> function capitalize () {
>   return this[0].toUpperCase() + this.substring(1);
> }
> function exclaim () {
>   return this + '!';
> }
>
> const result = 'hello'
>   ::doubleSay()
>   ::capitalize()
>   ::exclaim(); // "Hello, hello!"
> ```
>
> It's also weird that how the RHS of PO become weird when the function
> takes extra parameters. You can see how the code becomes polluted:
> ```javascript
> // Have fbFunc) with 0 parameters
> citizen::fbsFunc();
>
> // Add a parameter to fbsFunc()
> citizen::fbsFunc(param);
>
> // Have opFunc() with 0 parameters
> citizen |> opFunc;
>
> // Add a parameter to opFunc()
> citizen |> _ => opFunc(_, param);
> ```
>
> So we would be lying if we said the PO syntax is `param |> func`.
>
> The reality is:
> ```javascript
> // FBS syntax:
> param1::fbsFunc(param2);
>
> // PO syntax:
> param1 |> _ => opFunc(_, param2);
> ```
>
> This is no good.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151212/62cc25be/attachment.html>


More information about the es-discuss mailing list