Hacker News Reader

Comment by Cyykratahk | Hacker News Reader

We might be able to cross one more language off your wishlist soon, Javascript is on the way to getting a pipeline operator, the proposal is currently at Stage 2

https://github.com/tc39/proposal-pipeline-operator

I'm very excited for it.

View on HN

It also has barely seen any activity in years. It is going nowhere. The TC39 committee is utterly dysfunctional and anti-progress, and will not let any this or any other new syntax into JavaScript. Records and tuples has just been killed, despite being cited in surveys as a major missing feature[1]. Pattern matching is stuck in stage 1 and hasn't been presented since 2022. Ditto for type annotations and a million other things.

Our only hope is if TypeScript finally gives up on the broken TC39 process and starts to implement its own syntax enhancements again.

[1] https://2024.stateofjs.com/en-US/usage/#top_currently_missin...

Records and Tuples weren't stopped because of tc39, but rather the engine developers. Read the notes.

Aren't the engine devs all part of the TC39 committee? I know they stopped SIMD in JS because they were mire interested in shipping WASM, and then adding SIMD to it.

I would say representatives of the engine teams are involved. However not involved enough clearly, because it should have been withdrawn waaay before now due to this issue.

It was also replaced with the Composite proposal, which is similar but not exactly the same.

I wouldn’t hold your breath for TypeScript introducing any new supra-JS features. In the old days they did a little bit, but now those features (namely enums) are considered harmful.

More specifically, with the (also ironically gummed up in tc39) type syntax [1], and importantly node introducing the --strip-types option [2], TS is only ever going to look more and more like standards compliant JS.

[1] https://tc39.es/proposal-type-annotations/

[2] https://nodejs.org/en/blog/release/v22.6.0

I was excited for that proposal, but it veered off course some years ago – some TC39 members have stuck to the position that without member property support or async/await support, they will not let the feature move forward.

It seems like most people are just asking for the simple function piping everyone expects from the |> syntax, but that doesn't look likely to happen.

I don't actually see why `|> await foo(bar)` wouldn't be acceptable if you must support futures.

I'm not a JS dev so idk what member property support is.

Seems like it'd force the rest of the pipeline to be peppered with `await` which might not be desirable

    "bar"
    |> await getFuture(%);
    |> baz(await %);
    |> bat(await %);

My guess is the TC committee would want this to be more seamless.

This also gets weird because if the `|>` is a special function that sends in a magic `%` parameter, it'd have to be context sensitive to whether or not an `async` thing happens within the bounds. Whether or not it does will determine if the subsequent pipes are dealing with a future of % or just % directly.

It wouldn't though? The first await would... await the value out of the future. You still do the syntactic transformation with the magic parameter. In your example you're awaiting the future returned by getFuture twice and improperly awaiting the output of baz (which isn't async in the example).

In reality it would look like:

    "bar"
    |> await getFuture()
    |> baz()
    |> await bat()

(assuming getFuture and bat are both async). You do need |> to be aware of the case where the await keyword is present, but that's about it. The above would effectively transform to:

    await bat(baz(await getFuture("bar")));

I don't see the problem with this.

Correct me if I'm wrong, but if you use the below syntax

  "bar"
    |> await getFuture()

How would you disambiguate it from your intended meaning and the below:

  "bar"
    |> await getFutureAsyncFactory()

Basically, an async function that returns a function which is intended to be the pipeline processor.

Typically in JS you do this with parens like so:

(await getFutureAsyncFactory())("input")

But the use of parens doesn't transpose to the pipeline setting well IMO

I don't think |> really can support applying the result of one of its composite applications in general, so it's not ambiguous.

Given this example:

    (await getFutureAsyncFactory("bar"))("input")

the getFutureAsyncFactory function is async, but the function it returns is not (or it may be and we just don't await it). Basically, using |> like you stated above doesn't do what you want. If you wanted the same semantics, you would have to do something like:

    ("bar" |> await getFutureAsyncFactory())("input")

to invoke the returned function.

The whole pipeline takes on the value of the last function specified.

Ah sorry I didn't explain properly, I meant

  a |> await f()

and

  a |> (await f())

Might be expected to do the same thing.

But the latter is syntactically undistinguishable from

  a |> await returnsF()

What do you think about

  a |> f |> g

Where you don't really call the function with () in the pipeline syntax? I think that would be more natural.

It's still not ambiguous. Your second example would be a syntax error (probably, if I was designing it at least) because you're missing the invocation parenthesis after the wrapped value:

    a |> (await f())()

which removes any sort of ambiguity. Your first example calls f() with a as its first argument while the second (after my fix) calls and awaits f() and then invokes that result with a as its first argument.

For the last example, it would look like:

    a |> (await f())() | g()

assuming f() is still async and returns a function. g() must be a function, so the parenthesis have to be added.

I worry about "soon" here. I've been excited for this proposal for years now (8 maybe? I forget), and I'm not sure it'll ever actually get traction at this point.

A while ago, I wondered how close you could get to a pipeline operator using existing JavaScript features. In case anyone might like to have a look, I wrote a proof-of-concept function called "Chute" [1]. It chains function and method calls in a dot-notation style like the basic example below.

  chute(7)        // setup a chute and give it a seed value
  .toString       // call methods of the current data (parens optional)
  .parseInt       // send the current data through global native Fns
  .do(x=>[x])     // through a chain of one or more local / inline Fns
  .JSON.stringify // through nested global functions (native / custom)
  .JSON.parse
  .do(x=>x[0])
  .log            // through built in Chute methods
  .add_one        // global custom Fns (e.g. const add_one=x=>x+1)
  ()              // end a chute with '()' and get the result

[1] https://chute.pages.dev/ | https://github.com/gregabbott/chute

PHP RFC for version 8.5 too: https://wiki.php.net/rfc/pipe-operator-v3

All of their examples are wordier than just function chaining and I worry they’ve lost the plot somewhere.

They list this as a con of F# (also Elixir) pipes:

    value |> x=> x.foo()

The insistence on an arrow function is pure hallucination

    value |> x.foo()

Should be perfectly achievable as it is in these other languages. What’s more, doing so removes all of the handwringing about await. And I’m frankly at a loss why you would want to put yield in the middle of one of these chains instead of after.

Cool I love it, but another thing we will need polyfills for...

How do you polyfill syntax?

Letting your JS/TS compiler convert it into supported form. Not really a polyfill, but it allows to use new features in the source and still support older targets. This was done a lot when ES6 was new, I remember.

Polyfills are for runtime behavior that can't be replicated with a simple syntax transformation, such as adding new functions to built-in objects like string.prototype contains or the Symbol constructor and prototype or custom elements.

I haven't looked at the member properties bits but I suspect the pipeline syntax just needs the transform to be supported in build tools, rather than adding yet another polyfill.

I believe you meant to say we will need a transpiler, not polyfill. Of course, a lot of us are already using transpilers, so that's nothing new.

Reply on news.ycombinator.com