Simpler Syntax about proposal-pipeline-operator HOT 11 CLOSED

It is simpler because it avoids nesting and needs less meta characters.

As the proposal notes, nesting makes reading harder.

from proposal-pipeline-operator.

in my opinion |> is better than ~> because
1 - | is literally called pipe. hence "pipeline operator"
2 - visually when scanning code ~ and > blend together you may confuse it with bitwise NOT
there are many other reasons why other variants were rejected, you can refer readme or closed issues
I agree that proposed syntax is not the simplest but after all this is something completely new in this language. we all gonna feel awkward using it until we are used to. maybe later all we all will figure out something better (like we did for async/await syntax for promises)

from proposal-pipeline-operator.

That’s not nested, though - it’s linear.

from proposal-pipeline-operator.

Why is that simpler? That also seems more akin to F# syntax, which was rejected in favor of Hack (specifically, assuming that a value is a function)

from proposal-pipeline-operator.

Besides the fact that the location of the 7 argument seems "misplaced" visually (the arguments occur before the function call), it's also not clear how you would translate this:

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

Or this

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

to your version.

from proposal-pipeline-operator.

Yup, the core idea here is just F#-style again. See #221 for why that was rejected by the committee and is not being pursued.

It is simpler because it avoids nesting

The only nesting in your examples is in the original non-pipelined code, where calls are nested inside each other. The pipeline'd version just has functions being called - that's not nesting.

from proposal-pipeline-operator.

Besides the fact that the location of the 7 argument seems "misplaced" visually (the arguments occur before the function call),

That is the point of pipes, isn't it?

it's also not clear how you would translate this:

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

It would become: a = b,7 ~> c,8 ~> d

Or this

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

That is: a = b,7 ~> 8,c ~> d

from proposal-pipeline-operator.

That is the point of pipes, isn't it?

No, the point is to linearize nested code.

from proposal-pipeline-operator.

That is the point of pipes, isn't it?

No, the point is to linearize nested code.

That is what I mean.

Nested:

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

Linearized:

a = b,7~>c~>d

from proposal-pipeline-operator.

How so? Because % and 7 are not function calls? We can "fix" that by replacing 7 with e().

Current proposal:

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

My proposal:

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

The issue with the current proposal is that it tries to avoid nesting, support multiple input parameters and use pipes that only carry a single value. And therefore must fail in at least one aspect. It fails in regards to nesting.

from proposal-pipeline-operator.

Because any sensible codebase would pad |> with newlines or spaces, and because you only have one pipeline, in both examples.

from proposal-pipeline-operator.