5 ms·

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 bel

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

packetlost 2y ago
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.
- porridgeraisin 2y ago
  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.
  - packetlost 2y ago
    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.

packetlost 2y ago

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.

porridgeraisin 2y ago
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.
- packetlost 2y ago
  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.