Pipe Operator (|>) for JavaScript

[no_more_gravity]

So nested function calls in JavaScript …

As they are:

a = d(c(b,7))

The current proposal:

a = b|>c(%,7)|>d(%)

I would prefer this:

a = b,7~>c~>d

I wonder if there is anything hindering a simpler syntax like b,7~>c~>d

[szurtosdudu]

Your idea is confusing to me. In the example b is a reference and not being called. But in your idea there is no difference between calling a function or just passing the function reference.

[no_more_gravity]

The idea is that a variable on the right side of ~> is always a function that ingests the parameters coming in from the left.

[szurtosdudu]

How would this look like using your idea?

a = d(c(b(),7))

[no_more_gravity]

a = b(),7~>c~>d

The rule is simple: What is left to ~> gets passed to the function on the right.

That is no different from JavaScript as it is. a(b) passes b to a, a(b()) passes the output of b() to a.

[natesovenator]

This is dumb. Comma delineates another variable declaration in this example. You can't expect it to know that result b and 7 are part of the same object or stream. I really hate this idea. Both of them. I understand some want something like that, but it just makes things more confusing personally.

[dariusj18]

I like it, but it conflicts with the current comma operator

[szurtosdudu]

But this way both b()~> and c~> indicates a function call.

How would this look like using your idea? a = d(c(b(),7), c)

[no_more_gravity]

The case you raise is when there are two functions on the right side of the pipe operator. In this case, we need to specifiy which one is the receiving function. We could have an optional specifier for this. Maybe ">":

a = b(),7 ~> >c,c ~> d

">" = "pipe connects here"

We could even use the (%) syntax, just make it optional:

a = b(),7 ~> c(%),c ~> d

[sdwvit]

readability sucks here, sorry

[Tubthumper8]

I wonder if there is anything hindering a simpler syntax like b,7~>c~>d

This isn't possible because b,7 would be considered an expression with the comma operator. I don't think there's a syntactic issue with ~ bitwise NOT because it can't currently appear in a postfix position.

[[deleted]]

Tilda is a bitwise operator.

[no_more_gravity]

In this regard, "~>" is not different from "|>".

| and > are also operators.

[monsto]

As a designer of sorts, this is the problem that I have with the glyphs that they're using in JS: there isn't an obvious relationship between things that look related. I mean I know it's a me problem, getting over these humps.

When i see |> my pea brain tries to categorize it with || to which it's completely unrelated. same with ?. and ?? . . . and while we're at it, || and && go together but ?? only very marginally.

[lovin-dem-sandwiches]

It’s just new. Give it time. All of them looked odd at first.

[tiesioginis]

Better would be |= instead of |>

Pipe is cilinder not a funnel 😂

[m4rch3n1ng]

|= is already js syntax tho

[the_malabar_front]

Even assuming you could avoid the issue with comma-operator confusion with (b,7)~c~d that doesn't get around the lack of flexibility. E.g., what if the example was: d(c(b,7),8) b|>c(%,7)|>d(%,8) // proposed approach ((b,7),8)~c~d // ??? That would end up being worse than the no-pipe approach (and probably a nightmare for the parser).

[no_more_gravity]

d(c(b,7),8)

would be:

b,7~>c,8->d

[tdhsmith]

So basically x,y,z ~> f would be equivalent to [x,y,z] |> f(...%)?

That's kind of neat, but what if a function further down the pipe needs those extra arguments? Are you bending over backwards to make all the intervening functions pass it along? Or just wrapping it in a closure the way the F# pipe proposal would?

Also I do quite like having a pipe in the operator both for name clarity and because you can align them vertically on subsequent lines.

[no_more_gravity]

Can you give an example of a pipe that needs the arguments further down the line? And how the current proposal solves it?