Bikeshedding the Hack topic token

[js-choi]

This issue is for bikeshedding the spelling of the topic token in Hack pipes, branching off from #75 (comment). For more context, see the Hack pipes proposal and the wiki home page.

The table has its own editable page on the wiki. Please read this table first before contributing to this issue.

Please also keep discussion on topic: bikeshedding the topic token for Hack pipes. For other topics, search for other existing issues. Thank you!

Old obsolete questions

These currently are the most topical bikeshedding questions that I see now:

1. What is the optimal tradeoff in writability (easily typed ASCII soup, e.g., ?, or easily typed privileged valid variable, e.g., $) versus readability (less easily inputted non-ASCII syntax, e.g., ■)?

2. Related to question 2: Can non-ASCII Unicode syntax characters be considered for the pipe placeholder, or must they be categorically excluded?

   A list of all possible Pattern_Syntax Unicode characters is available.

3. If question 3’s answer is that non-ASCII Unicode syntax may be excluded, which non-ASCII syntax character would be visually understandable and/or less difficuldif­fi­cultt?

   Many non-ASCII symbols are easily inputted in certain OSes. For instance, in macOS, several dozen typographic characters are directly typable using Option or Option + Shift (image of keyboards with various active modifier keys via Macworld article. It may be worth determining if there is an intersection of these easily typable non-ASCII characters across the default keyboard layouts of many OSes.

4. For nullary operators vs. valid variable identifiers: How important is it that the placeholder be statically analyzable?

   A nullary operator can be always be statically recognized in the RHS. In contrast, a valid identifier can be statically recognized only if the rule is: “Tacit function calling may occur only when the RHS is a bare identifier, rather than allowing the RHS to be any arbitrary expression without a placeholder.”

5. Operator vs. identifier again: How often would someone want to use an identifier from an outer lexical context of the same name as the pipe placeholder?

   If the placeholder is $, how often would a programmer want to use jQuery’s $ or another externally defined $ in a pipe’s RHS, as well as the pipe placeholder? How often would they be surprised if they could not, without defining a dummy variable for the outer $? How bad of a footgun (i.e., bug by programmer-unexpected behavior) would this be?

6. How much should the pipe placeholder stay compatible with @rbuckton’s higher-order functional operators, which possibly would use {…}?

7. @rbuckton proposed a partial-application placeholder that may be explainable by multiple topic placeholders. In other words, the pipeline syntax might be completely unifiable with the PA syntax with the right enhancements.

   Assuming a future shorthand “pipe-function operator” like +> (which would be an abbreviation for x=>x|>), then @rbuckton’s proposal’s f(?, 3) would instead be +> f(?, 3), which in turn would be shorthand for x=>x|> f(?, 3).

   Creating non-unary functions could be done
   by adding numbers to placeholders,
   such as ?0, ?1, ?2, etc.
   For instance, example.sort(+> ?0 - ?1)
   would mean example.sort((x, y) => x - y).
   (?0 would be equivalent to plain ?.)

   Which placeholders would have any problems with staying forward compatible with such a future proposal?

As of 2022-07-11, I like ^^ then more distantly $_, @@, %%, and #_.

[ljharb]

There's a few choices that use ? but might avoid some of the confusion:

• <?>
• {?}

Also, I find ^^ confusing in that what it does is not related to what ^ does.

[aikeru]

FWIW, I really like ^^. I find it clever, and illustrative in that it points up, as though at the previous expression which is likely to be the LHS of the pipeline operator, reminding you where the value comes from.

[ljharb]

Pipelines will be single-line just as often as multiline; so "points up" and "points at the previous" won't consistently be the same.

[littledan]

I take it that, if we go down the Hack-style path, we're not trying for any kind of path for the placeholder to be subsumed by @rbuckton's partial application proposal, and therefore should avoid using the same token, is that right?

[gilbert]

My 2c: I personally really like $ as the placeholder variable binding. Because it's a valid identifier, it feels like an actual variable, which it certainly is (albiet smaller in scope). It also prevents the Hack-style proposal from claiming another operator that might be useful for future proposals.

I think the "jQuery problem" is probably overblown for these reasons:

• How many libraries out there actually expose a global $? I would imagine very few.
• The pipeline operator does not impede using these libraries. Rather, using these libraries impedes using the pipeline operator, which is not a big deal.
• jQuery would hardly benefit from the pipeline operator anyway since it uses heavy method chaining.
• If you're not using global scripts and using modules instead, then you can easily rename your import / require variable to something other than $.
• _ would still available, and is much more commonly used for utility functions (lodash, underscore, rambda, etc.), although becoming less so due to static ES module imports.

[mAAdhaTTah]

Is it at all possible to use $ in the partial application proposal? If we're trying to leave open the door for a partial application proposal in the future, we could end up with two different syntaxes for partial application / placeholders, one inside pipelines and one outside.

[littledan]

@mAAdhaTTah I don't think it's possible for partial application to use $ unless there's a token which is used to start off the partial application expression. The current partial application proposal does not have such a token.

[js-choi]

@littledan: I take it that, if we go down the Hack-style path, we're not trying for any kind of path for the placeholder to be subsumed by @rbuckton's partial application proposal, and therefore should avoid using the same token, is that right?

From what I could tell, syntactic partial application could use the same placeholder as Hack style iff syntactic partial application were forbidden in every placeholder-using pipe’s RHS. This could be a footgun—it creates a hidden context dependency between two very different results, which may cause the programmer to accidentally commit a mode error—but if we logically proceed anyway:

Proposal 2: Hack Style Only and Proposal 4: Smart Mix would forbid syntactic partial application in the RHS of all pipes—or, rather, the parser would always interpret the presence of a RHS placeholder as a pipe placeholder, not a partial-application placeholder. For instance, if |> is always a Hack pipe and ? is the placeholder for both |> and partial application, then f(?, 3) would be partial application, and x |> f(?, 3) would be f(x, 3).

Proposal 3: Split Mix would forbid syntactic partial application in the RHS of Hack pipes. It could also forbid it in the RHS of F-sharp pipes but it could also allow them. If |> is an F-sharp pipe, |: is a Hack pipe, and ? is the placeholder for both |: and partial application, then f(?, 3) would be partial application, x |> f(?, 3) would be f(?, 3)(x) (or it could be a syntax error), and x |: f(?, 3) would be f(x, 3).

If that analysis is correct, I’ll add it to the original post’s ? option. The problems of hidden contextual dependency—and of visual confusion with nullish coalescing and optional method chaining (assuming that syntactic partial application would stick with ?)—would remain.

[ljharb]

I would be very opposed to using any valid identifier - including $. It is a very common pattern to do var $ = document.querySelectorAll as well, for example - it’s not just about globals.

Shadowing bindings is fine when users explicitly choose the identifier - it would not be ok with me that a magic implicit binding would appear that shadows my code just for using an operator.

[barneycarroll]

I prefer personally ?, but I think it's worth unpacking 'visually confusing'. I think the statement that it is visually confusing in relation to the two other stage 1 proposals is misleading — those statements are more visually confusing with each other and with the ternary operator than anything else. Even if both of those get through, the ? placeholder proposal should not be held back on their account.

The ambiguity only creeps in when placeholders are nested in further expressions — @gilbert's original example being a placeholder in a ternary expression: ? ? : foo. This is the kind of scenario where the other two stage 1 operator proposals become problematic, when ?? can be read as either an optional chain on the placeholder.

It's a truism that nested ASCII operations are difficult to parse, but I think the placeholder is a special case inasmuch as it already bears the application-space cognitive weight of a deferred value within a special lexical scope of a higher order operation (the pipeline). So the situation only becomes complicated when we allow that the placeholder be used as an operand within a further expression nested inside a pipeline. Might it be worth outlawing that particular condition? — that is to say, a placeholder must be standalone, invocable only with ( or , either side of it?

In passing, I am firmly against the idea that an otherwise valid generic reference (like _ or $) be special cased. There is a special kind of semantic ambiguity introduced in scenarios like that of this in class arrow methods, when lexical parsing rules change based on higher order context. To do that with something which is otherwise up to user semantics is by all accounts a really imposing proposal (I foresee eslint rules to try and retro-ban them to compensate for this, invalidating previously legitimate and self-explanatory code).

[stephaneraynaud]

What about parameters with a name ?
for example:

anArray
  |array> pickEveryN(array, 2)
  |array> array.filter(...)
  |filteredArray> makeQuery(filteredArray)
  |query> await readDB(query, config)
...

Then one could write something like this:

anArray
  |$> pickEveryN($, 2)
  |$> $.filter(...)
  |$> makeQuery($)
  |$> await readDB($, config)
...

I think this would improve code readability, as there may be a lot of transformations applied. If I want to read one particular line, I won't know what's passed to the function and what's for.

Other proposal, reuse arrow functions : [edit: actually, I noticed this is proposal 1]

anArray
  |> array => pickEveryN(array, 2)
  |> array => array.filter(...)
  |> filtered => makeQuery(filtered)
...

I like this proposal because it can be used with destructuring and stuff like this, while being readable.

There are probably a lot of issues with those proposals, but my main idea is that variables like "$" or "^^" lack of readability and are not really elegant (from my point of view).

[mAAdhaTTah]

Whichever token we choose is going have an effect on the placeholder syntax, either by producing two different placeholder syntaxes (which I'd prefer to avoid), by superseding the placeholder syntax (effectively killing it), or by forcing its hand (requiring it to use the same token). We should probably decide which approach we're taking and keep that in mind as we bikeshed the token for use in the pipeline.

---

@bisouduperou I think we ran into problems with a similar proposal for await, e.g. this:

x |$> pickEveryN($, 2)

could be parsed as:

x | ($ > pickEveryN($, 2))

[charmander]

Reusing arrow functions’ arrow works very well for most purposes, but not for await.

[aikeru]

Honestly I just really hope any form that has a placeholder variable of any shape or spelling gets adopted, because it adds tremendous power and flexibility to an operator that would otherwise be much more limited and constrained... Thanks for letting me add my 2c.

[js-choi]

In #84 (comment) I used a ## nullary operator as a pipe placeholder. It looks nice and it doesn’t mess up GitHub’s current JavaScript syntax highlighting, but it probably would be quite visually confusing with private fields, so I don’t actually think it’s a good idea, heh.

[gilbert]

Ok, if $ is too commonly used in user-land, then how about $$, like the actual Hack pipe operator?

[mAAdhaTTah]

@gilbert I was also thinking about $_ as another possibility.

[stephaneraynaud]

Let's try to not end up with smileys please $_$

[js-choi]

Ah, $_ brings back dormant memories of Perl…

For what it’s worth, Perl 6 actually turns Perl 5’s $_ into an impressively unified concept of a lexical “topic variable”, which may be lexically bound using a given block or a for block and which is implicitly used by many other types of statements, operators, and functions, making for rather pithy tacit code. Think of it like linguistic topics. And in general, Perl 6’s design (fun fact: they actually released 6.0 some time back) is worth checking out you want to dive into the heart of some ingeniously mad and madly ingenious PL design.

I am in no way suggesting that an implicit topic variable be a thing in JavaScript beyond Pipe Proposal 2/3/4, though it’s pretty fun to think about.

[ljharb]

@gilbert tbqh, i very strongly would object to any valid identifier there - it’s not just about “commonly used” for me, it’s about “ever used”.

[gilbert]

@ljharb I think such a strong stance to take would make sense if $$ were made globally available, but here it's only on the right-hand side of a pipeline – a very small scope, of which a programmer consciously introduces by writing |> in the first place.

[ljharb]

Magically introducing an implicit binding that shadows something defined in an outer scope is with-like behavior, and after we all worked so hard to remove with from strict mode, I’d think we’d be loath to reintroduce it.

[gilbert]

I agree it's implicit, but I would not equate to with. Yes we'd be loath to reintroduce with, but this is not remotely the same thing.

[rbuckton]

PowerShell also uses $_ as a topic variable in a number of places:

// pipes
Get-Files | ForEach-Object { Out-Host $_ };

// catch blocks
try { ... }
catch [System.Exception] {
  Out-Host $_.Exception.GetType().FullName; 
}

// filters/functions
function Foo {
  begin { ... }
  process { Out-Host $_; }
  end { ... }
}

Of course, that's because every variable in PowerShell is prefixed with $...

[aikeru]

Ah, $_ brings back dormant memories of Perl…

PowerShell also uses $_ as a topic variable in a number of places:

FWIW, Ruby uses this too. If JS were to adopt $_ as a topic variable or something like it, there's lots of precedent.

[jridgewell]

there's lots of precedent.

Node's also set precedent with _ being the last evaluated expression, but if it's defined in-scope it the variable you set it to.

[js-choi]

There is also Safari Web Inspector’s use of $1, $2, … to denote previously evaluated expressions in its console REPL, I suppose.

I used to be very against using a valid identifier for a pipe placeholder, but being reminded of Perl and Ruby made me realize that it might not be that weird. Then again, that there is an implicit binding at all in a Proposal-2,3,4 pipe is relatively unprecedented in ES. with was very bad especially because of its mucking up of static optimization, which Proposal-2,3,4 pipes do not have at all. But could using a valid identifier make static analysis of a pipe’s RHS—e.g., to determine whether there is no placeholder in the RHS—more difficult?

I plan to have my Babel plugin for Proposal 4 support configuration of what its placeholder is, to encourage experimentation (if its tokenization permits it). What its default placeholder should be, I don’t yet know. Maybe a non-ASCII placeholder by default might be interesting after all, haha.

[stephaneraynaud]

I don't think it's about weirdness but about origin. That you don't know about what an operator means is ok. You may don't know what "yield" or "await" means, because those are operators. But a valid identifier is, by default, a variable previously defined somewhere. By adding valid identifiers like "$_", you will need to ask yourself "am I in pipe ?" "does it come from pipe" "is it a global / simple variable?". I deeply encourage to avoid such (little) confusion.

While I personnally prefer meaningful placeholders ("$_" is as readable as "let thing = stuff()"), why not using @ as placeholder?

anArray
  |> pickEveryN(@, 2)
  |> @.filter(...)
  |> makeQuery(@)
  |> await readDB(@, config)
...

[sant123]

What about $# like shell count parameters?

value |> foo($#)

[Daniel15]

What about $# like shell count parameters?

value |> foo($#)

This looks a bit weird because JavaScript doesn't prefix variables with $ like shells do.

[sant123]

What about $# like shell count parameters?
value |> foo($#)

This looks a bit weird because JavaScript doesn't prefix variables with $ like shells do.

Yes but you can still do it, the advantage with # is that you will not break existing JS code. $# can’t be defined by anyone.

[mybearworld]

The shebang syntax #! does exist, but it'll only be ever used as the first two characters in a file (and it's only legal in that position).

[bogdanbiv]

* would look nice, as it's often used as a kind of placeholder value meaning "anything can go here". Of course, that's already used by the multiplication and exponent operators, so this probably shouldn't be used, but it's worth thinking about (maybe [*] or <*>?)

Why [*] and not [_] or |_|?

// worst case would be:
[[2, 1, 3], ["AAA", "BBB", [""]]]
  |> pickOne([_][0], "concat")
"2concat"

My impression is people hate three character tokens, at least they hate having to use ===, otherwise ___ would have been a nice pick. My impression is we need to use the worst examples to countervalidate what would not work

[mybearworld]

_ is a valid identifier right now. [_] is an array with one element which is the variable _, and |_| can appear in the context of 1|_|2. ___ is also a valid identifier.

[JAForbes]

I'd really like it if the particular binding token was reused elsewhere in the language. I think it would also be great if we could reuse or extend existing parts of the language instead of adding a new special symbol.

Maybe we can let users bind their own name by extending the existing syntax for label statements in the language.

x
|> $: f(x,$)
|> it: f(it)

And if the function is unary you can skip the name

x
|> f |> g |> it: await h(it, 2) |> i |> j |> it: await k(it, 4)

They aren't arrow functions so any concerns about performance / closure creation is allayed, and being able to name intermediate variables would probably be useful for long pipes.

I also find it pretty easy to follow what is going on here: it: await h(it, 2). We are so used to a colon after a name as a key/attribute/parameter definition the syntax largely explains itself.

If you want to get super terse, its only 2 extra characters.

|> await(#, 4)
 
// vs

|> x: await(x, 4)

But for that 2 character cost we get the ability to bind more human readable names, and reuse an existing part of the language.

And the same idea could be applied to those other language features even legacy ones like if / for and switch e.g.

switch (something(...)) it: {
   case 5: return it * 2
   default: return it * 3
} 

We saw these sort of bindings in other languages. Rust and swift have let bindings / pattern matching in loops. Zig also has a similar feature.

Currently the above syntax is invalid in JS so its not a breaking change, all that is needed is to differentiate between a label binding in an expression and a label binding directly after a continue / break command.

Brief aside: I was very much in favour of F# pipelines but I now just want this language feature to be the best that it can be no matter what the specific syntax is.

[mybearworld]

"Hack pipes favor more common expressions" and "Hack pipes might be simpler to use" seem to apply just as well to that variant of F# pipes as well.

[nmn]

@mybearworld We are no longer discussing F# pipes. I prefer them too, but Hack Pipes are more likely to actually ship and if you keep arguing we will never get any pipe operator.

Further, this issue is only about the token to be used in the case that we move forward with the Hack pipes approach. Your comment doesn't belong here.

[mybearworld]

I was responding to the comment above about extending the label syntax.

[sant123]

What about:

value |> foo(!!)?

Yeah would be cases like

value |> foo(!!bar)

But can be handled as a valid token if !! is only found. Also is not disqualified.

[mybearworld]

That would be ambiguous. foo |> !!(bar) could be foo |> (!!)(bar) or foo |> !(!bar).

[zlumer]

@nmn

if you keep arguing we will never get any pipe operator.

I'd argue that no pipe operator at all is much better than this abomination.

[nmn]

@zlumer That argument doesn't belong in this issue either. Read the title. Make that argument in a different issue.

[pedro00dk]

Hello everybody.
First contribution here. This issue is very long, so I did not read through it entirely.
It seems most suggestions are around small static tokens, and a few of them allow the developer to set a variable name, but requiring it to first be declared and then used.

I'm not sure if it this was considered already, but it could be interesting to have a dynamically named variable prefixed by a token that tells it is the pipeline token, without eager declaration.

const greeting = 'fellow user'
    |> `hello ${#user}`
    |> #lower.toUpperCase()

const occurences = 'my very long string'
    |> [...#string, ...#string]
    |> Object.groupBy(#doubledChars, v => v)

In this case the token would be a combination of prefix and JS identifier (#<identifier>).
It would not conflict with private properties, which must always be accessed via dot notation.
It would also not conflict with normal variables because of the token prefix.
<identifier> is dynamically assigned, it does not need to be declared eagerly.
Different <identifier>s can be used on different stages of the pipeline.

Since _, and $ are valid identifiers, #_, #$, would also be valid (same example as above with short tokens):

const greeting = 'fellow user'
    |> `hello ${#_}`
    |> #_.toUpperCase()

const occurrences = 'my very long string'
    |> [...#$, ...#$]
    |> Object.groupBy(#$, v => v)

My suggestion would be to use # as token prefix, as it is being used for private properties, so it already denotes a variable or property vibe, and is used in some new proposals like the tuple and records. So it would not be too alien for developers like some other suggestions I saw. AFAIK it would not introduce any ASI issues too.

The two issues that I see with this approach atm are:

• A token used multiple times in the same pipeline stage could be given multiple identifiers, but that is really a very minor, we either allow it or not.
• Since it is a dynamic identifier, not sure if this would pose any implementation issues by the JS engines.

[shicks]

It would not conflict with private properties, which must always be accessed via dot notation.

This is not so - you can also write #priv in obj for "brand checking", and that would conflict with using one of these identifiers as LHS of in. It's a very tiny conflict, but enough to be a problem.

[yordis]

This issue is very long, so I did not read through it partially.

@pedro00dk trust me! We know! Dont worry, "bikeshedding" issue was created to give space to people to, well, bikeshed. In all honestly, by now, we collected enough bisons that we ran out of combinations of characters and ideas. We should start reaching for egyptian holographic.

[pedro00dk]

@shicks
Interesting, I did not know it could be used with the in operator. Although, I'd say # could still be a valid option. I have no data to back me up, but I suppose this brand checking is not a common pattern. When inside a pipeline:

• Cast the in LHS to string (|> `${#token}` in obj). It is not convenient though, and some devs would not understand the need for the cast. It also would not work for symbols.
• Always evaluate the token when used in the in LHS. Meaning brand checking can't happen in a pipeline. It is simpler overall, and the in operator kind of is already a mini monster, by accepting something that is not a valid value, better leave the complexity to it.

Another ASCII option for token prefix could be backslash \, AFAIK it is only part of the JS grammar inside strings and regex to escape characters, so it would also not introduce ASI issues, it looks clean, and kind of goes with the lines and angles theme of |>

const greeting = 'fellow user'
    |> `hello ${\user}`
    |> \lower.toUpperCase()

const occurences = 'my very long string'
    |> [...\string, ...\string]
    |> Object.groupBy(\doubledChars, v => v)

[mybearworld]

A major advantage of the pipe operator is that you don't need to come up with a name for every step. This would get into the way of that.

[pedro00dk]

@mybearworld
Since the idea is that the token would just be a prefixed identifier, you can just use a short one. \_, \$, \v, etc..., only two characters. I agree that for most use cases a short identifier would definitely suffice, but being able to name the topic, even though it is just decorative, can help code reading and serve for documentation purposes, especially in longer pipelines with more complex operations.

[mybearworld]

The majority of pipes would be pretty simple, though. If the operations done in pipes get more complex where having names for the topic would be beneficiary, there are still options without requiring a named topic:

• Resort to using regular variables:

  const string = 'my very long string';
  const doubledChars = [...string, ...string];
  const occurences = Object.groupBy(doubledChars, v => v);

• Alternatively, use an IIFE:

  const occurences = 'my very long string'
      |> ((string) => [...string, ...string])(%)
      |> ((doubledChars) => Object.groupBy(doubledChars, v => v))(%)

[ljharb]

@shicks Interesting, I did not know it could be used with the in operator. Although, I'd say # could still be a valid option. I have no data to back me up, but I suppose this brand checking is not a common pattern. When inside a pipeline:

• Cast the in LHS to string (|> `${#token}` in obj). It is not convenient though, and some devs would not understand the need for the cast. It also would not work for symbols.
• Always evaluate the token when used in the in LHS. Meaning brand checking can't happen in a pipeline. It is simpler overall, and the in operator kind of is already a mini monster, by accepting something that is not a valid value, better leave the complexity to it.

Another ASCII option for token prefix could be backslash \, AFAIK it is only part of the JS grammar inside strings and regex to escape characters, so it would also not introduce ASI issues, it looks clean, and kind of goes with the lines and angles theme of |>

const greeting = 'fellow user'
    |> `hello ${\user}`
    |> \lower.toUpperCase()

const occurences = 'my very long string'
    |> [...\string, ...\string]
    |> Object.groupBy(\doubledChars, v => v)

its commonness is irrelevant; it would never be acceptable to prevent its usage in any otherwise valid context.

[rbuckton]

Another ASCII option for token prefix could be backslash \, AFAIK it is only part of the JS grammar inside strings and regex to escape characters, so it would also not introduce ASI issues, it looks clean, and kind of goes with the lines and angles theme of |>

The \ character can be used to escape unicode characters in identifiers: https://github.com/tc39/test262/blob/main/test%2Flanguage%2Fidentifiers%2Fother_id_start-escaped.js

[btoo]

A major advantage of the pipe operator is that you don't need to come up with a name for every step.

It would be useful to optionally name the token for handling nested pipes, lest we'd be limited to piping only the immediate pipe's values (without declaring intermediary variables)

The \ character can be used to escape unicode characters in identifiers: https://github.com/tc39/test262/blob/main/test%2Flanguage%2Fidentifiers%2Fother_id_start-escaped.js

one possible unintended ergonomic consequence of \ is having to escape them in stringified JavaScript (as would be the case in e.g. evals)

[zaygraveyard]

What about @pedro00dk's #<identifier> suggestion but require parenthesis in some way when used with in, as to distinguish it from "brand checking"?
Like 'key' |> (#_) in obj is equivalent to 'key' in obj, and 'key' |> #priv in obj is equivalent to #priv in obj (the "brand checking").

[mybearworld]

That would be pretty unintuitive and confusing behavior, I'd say.

[ljharb]

@zaygraveyard a private name is not just a string identifier with a # prefixed - it must always be statically present and can’t be referenced dynamically.

[zaygraveyard]

@ljharb I'm confused, where did I reference a private name dynamically?

[ljharb]

@zaygraveyard hm, on a reread i see that you did not, my apologies. the likelihood of confusion from your proposal, then, seems high :-p