Adding "hack" support to F# style with the "(eiffel) tower" operator "|>$=>"

[theScottyJam]

@tabatkins has put together this wonderful essay that weighs the differences between F# and hack style pipes, and ultimately concludes that the differences are minor, but hack-style is a little better, in part due to the fact that for most use cases, hack-style will be more concise.

I've got to agree with @tabatkins on all of this, however, as I mentioned in a comment over there (that I decided to bring up over here), there's a minor thing we can add to F#-style pipes, to have it reap almost all the same benefits as hack-style (all but the nice support hack-style has for await, but I'm ok having a more verbose solution for that).

But first - some background.

What we're aiming for is to find a simple, yet easy-to-read version of the pipeline operator. With that in mind, I want to make a comparison between two fictional pipeline operator syntaxes - |next> and % @.

id |next> ? + 1 |next> groupsFromUser(?, true) |next> rolesFromGroups(?)

id % @ ? + 1 % @ groupsFromUser(?, true) % @ rolesFromGroups(?)

What I want to point out from the above example, is how much more readable the |next> version is. Why? Because it's a single unit. % @ is two separate things, which adds a lot of visual clutter and makes it harder to glance at the expression and see what's going on. This is the issue that F# style pipes currently has: more often than not, an F# pipe requires a function literal afterwards, causing you to write three distinct "units" in order to do anything useful - the "|>", an identifier, and "=>":

id |> x => x + 1 |> u => groupsFromUser(u, true) |> g => rolesFromGroups(g, false)

Gross 🤮️

So what's the one thing we can add to F#-style pipes in order to save it? We can popularize the new "(Eiffel) tower" pseudo operator |>$=>, which combines those three units into one, and effectively brings the benefits of hack-style pipelining into F#-style. Notice that |>$=> is nothing more than the pipeline operator, an identifier, and "=>" smashed together into a single unit, but it greatly improves the readability of code. Here's the same example, using the tower operator:

id |>$=> $ + 1 |>$=> groupsFromUser($, true) |>$=> rolesFromGroups($, false)

You may argue that |>$=> is such a loooong operator, but remember that our goal isn't to reduce character count, it's to improve readability. If we wanted to write more concise code, we would just do what we can already do today - remove the pipeline operator and call the functions in a normal fashion. That will always be more concise than any pipeline operator proposal we come up with.

Here's some more examples, adapted from the README:

let newScore = person.score
  |> double
  |>$=> add(7, $)
  |>$=> boundScore(0, 100, $);

getAllPlayers()
  |>$=> $.filter( p => p.score > 100 )
  |>$=> $.sort()
  |> Lazy
  |>$=> $.map( p => p.name )
  |>$=> $.take(5)
  |>$=> renderLeaderboard('#my-div', $);

I love the power of the hack-style operator, but I also love the simplicity of F#-style (we're not having to add a special topic concept that's unique to a single operator). I know it's not conventional to do this kind of thing, but I advocate that we run with F#-style and attempt to popularize this tower operator with it (we can include it in the proposal's README, eventually put a page about it on MDN, etc), thus giving us the best of both worlds.

[theScottyJam]

Right after posting this, I realized there's a precedence issue when you do this kind of thing on one line:

// This:

id |> x => x + 1 |> u => groupsFromUser(u, true) |> g => rolesFromGroups(g, false)

// would be wrongly interpreted as:

id |> x => (
  x + 1 |> u => (
    groupsFromUser(u, true) |> g => rolesFromGroups(g, false)
  )
)

// It needs to be written as this instead:

id |> (x => x + 1) |> (u => groupsFromUser(u, true)) |> g => rolesFromGroups(g, false)

// which is even grosser :(

This means the tower operator really only works if each tower stands on its own line (and we ensure certain precedence rules are applied so that the next pipeline operator on the next line is interpreted as outside the function, not inside - something that may happen anyways).

This certainly isn't a deal-breaker, but an important-to-note downside of F#-style in general - it's not very clean if you're trying to place multiple pipeline operators with inline functions on the same line. There may be an intuitive way to fix this F#-style issue that I'll bring up in another issue a bit later.

[mAAdhaTTah]

This was unfortunately considered and rejected. See Split Mix

Edit: This is what I get for reading quickly. Nevermind, these aren't the same thing.

[lightmare]

but it greatly improves the readability of code

That's debatable. It's basically Hack plus clutter minus await/yield, which makes it strictly worse. F# style has some upsides, this isn't one.

NB: the Eiffel tower doesn't have a roof, nor a 🍺 belly. Looks more like 💰-fueled 🚀

[theScottyJam]

Haha, "rocket" operator - certainly has a nicer ring to it :)

It "improves readability" in relation to how F# currently stands. I agree that hack-style is more readable than what I'm proposing - the main downside is the extra syntax/semantic cost hack-style has. Not every project will use the cash-rocket operator either, just like some projects forbid the convenient use of !!.

[ducaale]

How about using >| for expressions and |> for functions?

let result = data
  |> filter(x => x % 7 == 0)
  |> pairwise
  >| #[0][0] + #[0][1]
  >| await asyncFn(#)

[theScottyJam]

Honestly, if we think the syntax/semantic baggage is worth it to actually add the hack-style operator, then I would rather have the hack-style operator alone. The one thing F#-style adds over hack-style is its ability to provide a function without explicitly calling it - I don't think there's enough value in this feature to warrant its own operator (this would be more valuable if JavaScript were a curried language, but it's not).

So, I'm ok with having a real and fake operator (I wouldn't be surprised if this ends up happening naturally if we go with F#-style), but not two real operators that do almost the same thing.

[kyleVsteger]

id |> x => x + 1 |> u => groupsFromUser(u, true) |> g => rolesFromGroups(g, false)

When broken into multiple lines this isn't that bad...

id 
|> x => x + 1 
|> u => groupsFromUser(u, true) 
|> g => rolesFromGroups(g, false)

[samhh]

Indeed it's not, and it's a feature that will predominantly be used by those of a functional mindset, which leaves open the door for optional currying and partial application.

id 
|> x => x + 1 
|> u => groupsFromUser(u, true) 
|> g => rolesFromGroups(g, false)

becomes

id 
|> add(1)
|> groupsFromUser(true) 
|> rolesFromGroups(false)

I know this point has surely been raised already, at least in other threads, but it's really already a solved problem. The mental overhead of learning this is surely less than learning the ins and outs of a more complex set of operators.

[tabatkins]

Right, a set of operators would need significantly more justification than just adding either single operator individually. The cost of converting a syntax optimized for one into the other is very small when measured against the cost of having to learn, use, and recognize two or more very-slightly-different operators, and I think it's fairly clearly not worthwhile.

Every bit of syntax we add to JS needs enormous justification. First, there's only so much space in ASCII to play around with, so we have to be judicious with it. Second, small, subtle differences are the bane of reading and writing; it's much better to have bright clear lines between features, even if it means some aspects aren't fully optimized.

[theScottyJam]

@samhh - it's a solved problem in curried languages. Javascript is not curried, nor are any most of the community-provided libraries. There's only a small minority of people who try to use Javascript in a curried fashion. This means, for the majority of people, your curried code example really isn't an option, as the functions you're trying to use wouldn't be curried.

Whatever route we go, we should try to make the pipeline operator fit in with how the Javascript community currently uses Javascript, not with how it could look if people started to curry more often. F#-style pipelines just aren't very ergonomic for the majority of Javascript users.

[theScottyJam]

@kyleVsteger

That particular example isn't that bad when placed into multiple lines, but many other use cases would be worse.

// F#-style
const result = shape
  |> shape => translate(shape, { left: shape.right, up: shape.bottom })
  |> shape => rotate(shape, `${deg}degrees`)
  |> shape => scale(shape, 2.0)

// hack-style
const result = shape
  |> translate(#, { left: #.right, up: #.bottom })
  |> rotate(#, `${deg}degrees`)
  |> scale(#, 2.0)

// The rocket pseduo-operator
const result = shape
  |>$=> translate($, { left: $.right, up: $.bottom })
  |>$=> rotate($, `${deg}degrees`)
  |>$=> scale($, 2.0)

In the end, none of these examples are horrible. There's only minor visual improvements between one style and the next.

[lightmare]

Javascript is not curried, nor are any of the community-provided libraries.

Actually, some are.

[theScottyJam]

Haha yes, I thought I changed that wording to say "Most of the community-provided libraries". Yes, there's certainly some out there, like Rambda.

[theScottyJam]

Well, it seems like there's a general dislike towards this idea, which is fine. It was a bit of a stretch anyways - I've never known a language to actually recommend using a pseudo-operator like this. I'll go ahead and close this.