Viability of using |: as the operator for Hack-style

[shuckster]

Pulling this from the readability thread. I hope this is different enough from both that and the Tacit unary function application section of the main proposal to warrant a separate discussion.

|: has been suggested as an alternative operator to |>

value 
  |: extractBusinessData(^) 
  |: await mergeWithWebServiceData(^) 
  |: processResults(^) 
  |: printResult(^);

This would avoid foreclosing on using |> for a potential future operator familial to FP'ers.

Quoting from @lozandier's essay:

While I'm adamant a tacit, first-class functional-composition pipeline operator should ship in the language as originally desired by this proposal, I'm even more adamant hack-style doesn't prematurely reserve the ubiquitous means of representing such operators for its usage.

--@lozandier

It seems fair to note that @mAAdhaTTah originally proposed |: for Split Mix. I don't want to speak for him other than to honour the originator of the idea, but I feel it's important to bring in this quote:

I just want to clarify that I was not suggesting I was open to Hack-style being |:

--@mAAdhaTTah

I hope it's okay to suggest it separately here.

EDIT - Correction from @mAAdhaTTah , it was originally suggested here: #75 (comment)

A few posts have in the readability thread popped up in support of |: (along with their respective emojis) so I thought we might be better off with a dedicated thread to expand on these thoughts and hear about the viability of this idea from the champions.

[sandren]

Adopting |: as the syntax for the proposed Hack-style operator leaves the language open to the possibility of introducing a proper |> operator in the future.

Doing so would alleviate at least some of the concern of those in the FP JS/TS community who are disappointed that the minimal or F# proposal did not reach Stage 2 and are afraid of being locked into pipe() forever.

However that would mean starting over with a new |> pipeline operator proposal at Stage 1. Is there someone who would champion it?

[mAAdhaTTah]

To be clear, I'm not the originator of the idea but linked back to this comment where it was originally suggested as the placeholder version for Split Mix.

[tabatkins]

The only reason for changing to |: would be to avoid taking |>, right? To the best of my knowledge, there's no suggestion that it's a better operator in some way?

[shuckster]

That seems to be the reason it resurfaced as a suggestion, yes.

Mind you, I'd welcome seeing fewer > characters amongst all that JSX. 🤔

[mmkal]

Another advantage is that it looks like a slightly judgemental 😐 face so could subtly shame people into not writing bad code.

[aadamsx]

I like the idea of |: operator as the "pipe" and also adding : as a matching placeholder like so:

// Hack with alternative pipe operator and placeholder |: & :

value 
  |: extractBusinessData(:)
  |: await mergeWithWebServiceData(:)
  |: processResults(:, 1, 2)
  |: printResult(:);

Makes it clear that the placeholder is associated with the pipe in a way.

[lightmare]

I like the idea of |: operator as the "pipe" and also adding : as a matching placeholder

You cannot have both, because it would lead to ambiguity:

one |: foo(:) |: +bar(:) // ambiguous
+bar(foo(one)) // is it this?
foo(one) | one + bar(one) // or this?

[aadamsx]

You cannot have both, because it would lead to ambiguity @lightmare

Will you please be more specific, for example:

// How can this:
one |: foo(:) |: +bar(:);

// Not be interpreated like this:
one |: foo(^) |: +bar(^): 

Thanks for your time.

[mAAdhaTTah]

@aadamsx Because | is bitwise OR, so it can be interpreted as:

one |: foo(^) | ^ +bar(^): 

The |: can be interpreted as either the pipe operator or a bitwise OR with the LHS value.

[tabatkins]

Yeah, : as a placeholder is really problematic on its own (I think it could produce ambiguous parses with the ?: trinary); combined with a |: pipe operator it just gets completely ambiguous from the get-go. Unary-plus is a source of so much fun potential ambiguity. ^_^

[lightmare]

Unary-plus is a source of so much fun potential ambiguity. ^_^

In this case unary plus is not the culprit, though ;) I used it because it helps to show where something goes wrong. It seems easier to spot than ambiguities caused by [] or conditionals. Such as one |: two[:] |: [:] or one |: foo(:) |: (: ? : : :).

I would add that even without those, : is kinda cursed, because it would also eliminate syntax options for potential future proposals like bind operator or array slicing.

[tabatkins]

Yup, let's just put the : placeholder to bed; it's definitely too problematic to consider both in current JS and for future JS proposals. If anyone wants to continue arguing for it, you can do so in #91, which is meant for discussing the topic token.

[shuckster]

While this thread mentions |: specifically, I have noticed the bikeshed tag (thank you) and also the HISTORY updates that point to the following comment from a proposal champion: #91 (comment)

Pull-quote:

I've even mentioned up-thread that I'd support a Hack-style "topic pipe" like ^> or ||> or -> along side a F#-style function pipe like |>. That's a separate issue, however, and maybe we can discuss that outside of this issue as something to bring before committee. --@rbuckton

I hope it's okay to place here as a cross-reference.