Pipeline Champions
2022-07-13
plaintext logs
prev next
source on github
13:42
<jschoi>
I think the f() |> ~ + ~ case is unfortunate enough to exclude ~ as topic, but f() |> ~~ + ~~ should work, right?
^^, ~~, %%, @@, ##.
14:13
<rbuckton (PTO: 7/5 - 7/16)>
Isn't ~~(n) still valid JS? I don't think doubling is a solution.
16:04
<jschoi>
You’re right; no doubled prefixes allowed.
16:54
<TabAtkins>
Yeah double binaries is good, double unaries isn't.
17:41
<rkirsling>
#~ though? ;)
18:26
<rbuckton (PTO: 7/5 - 7/16)>

Not even sure double binaries is good. What if we'd had pipeline before **, would we have excluded ** from the list of potential topics? What are the chances we might want to leverage a double binary for some other related math operation in the future?

I was tempted to suggest @it and banning it in a decorator (though you could still potentially do @(it)), except I'm fairly certain decorator test frameworks (or decorator support in existing frameworks) will pop up when decorators is finalized.

18:28
<rbuckton (PTO: 7/5 - 7/16)>
(especially since I already wrote one 7 years ago for TS decorators while exploring the feature, though I never published it)
19:09
<Ashley Claymore>
presumably 'banning' unary ~ in a pipe body is a very unpopular opinion. (I'm a ^^ fan, but just curious)
19:16
<rkirsling>
what's interesting about unaries though is that they don't warrant a separate pipe
19:16
<rbuckton (PTO: 7/5 - 7/16)>
Yes. TS compiler wants to use pipes and we internally use bitmasks, so we would be strongly against banning ~ or ^ inside a pipe
19:17
<rkirsling>
i.e. you can do ~~x |> foo(#) or y |> ~~bar(#), there's no need for |> ~~#
19:27
<rbuckton (PTO: 7/5 - 7/16)>

Inside the TS compiler, our binarySearch function returns the twos-complement of the greatest lower bound when a match isn't found, so result >= 0 equals an exact match, and ~result indicates an potential insert location. I could potentially see a case where someone could leverage ~ in a pipe such that:

binarySearch(array, value) |> (~ >= 0 ? array[~] : array[~~]); // greatest lower bound
binarySearch(array, value) |> (~ >= 0 ? array[~] : array[~~ + 1]); // least upper bound

As you can see, this wouldn't work with ~ or ~~ (or any arbitrary length of ~).

19:29
<rbuckton (PTO: 7/5 - 7/16)>

I much prefer the readability of an identifier here:

binarySearch(array, value) |> (it >= 0 ? array[it] : array[~it]); // greatest lower bound
binarySearch(array, value) |> (it >= 0 ? array[it] : array[~it + 1]); // least upper bound
19:32
<rbuckton (PTO: 7/5 - 7/16)>

Though we're much more likely to see the topic used with ~ in less ambiguous cases such as in the call to setEmitFlags below:

return factory.createBinaryExpression(...)
  |> setOriginalNode(~, node)
  |> setSourceMapRange(~, { pos: ..., end: ... })
  |> setEmitFlags(~, getEmitFlags(node) & ~EmitFlags.NoComments);
19:40
<jschoi>
For what it’s worth, I am slowly coming around to using an identifier.
But I think that it really ought to be considered a contextual keyword like await and yield.
The keyword would be something that, from now on, we would discourage developers from using as an ordinary variable, just like how developers should not use await and yield as ordinary variables.
19:42
<rbuckton (PTO: 7/5 - 7/16)>
If that's the case, I'd go for something like $_ or $$. I've seen __ used too often for unused parameters, i.e. f((_, __, x) => { ... })
19:42
<jschoi>
binarySearch(array, value) |> ($$ >= 0 ? array[$$] : array[~$$ + 1]);
binarySearch(array, value) |> (__ >= 0 ? array[__] : array[~__ + 1]);
19:42
<jschoi>
Right, that makes sense.
19:43
<rbuckton (PTO: 7/5 - 7/16)>
I generally prefer $_ over $$ despite it being a bit tricker to type, since _ often indicates a placeholder in multiple languages, and there's precedent in many shell scripts and some languages for $_.
19:45
<rbuckton (PTO: 7/5 - 7/16)>
Plus editors can easily offer a completion for $_ on the right of a |>, so its more likely someone just does $<tab>
19:51
<rkirsling>
yeah I've expressed before that something with _ would feel the most "obvious" to me
19:51
<jschoi>
I mildly prefer $$ to $_ because: $_ is already being used in some contexts like browser inspectors (although admittedly this is a niche case; there might be other extant uses), $$ is indeed easier to type, and $_ is uglier to me than $$. As you know, the fact that $_ but not $$ is valid syntax for variables in Bash/Perl/Ruby, so $_’s use is an incident of those languages’ peculiarities.
But this is a mild preference.
19:51
<rbuckton (PTO: 7/5 - 7/16)>
If the completion case is strong enough, a longer keyword like topic is potentially just as viable since an editor could rank it higher in a completion list.
19:52
<rbuckton (PTO: 7/5 - 7/16)>
$_ in dev tools is a power-user corner case that isn't used in any actual code and is fairly fragile anyways. I'm not as concerned about running into issues there.
19:55
<jschoi>
The most important thing for me is if $_ really is not being already used by libraries and such. The same would be with $$; common usage of $$ would make it much less attractive to me.
20:02
<rbuckton (PTO: 7/5 - 7/16)>

A quick search via GitHub's codesearch for language:js symbol:$$ shows a fair number of projects that use $$ as an alias for document.querySelectorAll. I found over 100+ files.

A similar search for language:js symbol:$_ has 18 results, though it tells me the results are not exhaustive. Of those 18 results, 15 are substring matches and don't count.

20:04
<rbuckton (PTO: 7/5 - 7/16)>
GitHub is telling me results are not exhaustive, but still only provides me with 18 total matches.
20:05
<Justin Ridgewell>
Does $_ get set while in the expression
20:05
<Justin Ridgewell>
I thought it was only done at statement positions
20:07
<jschoi>
Excellent data, thank you.
20:08
<jschoi>
I wonder how many people were using yield and await as variables before generators and async functions…not that it matters. New uses ought to be be zero now.
20:08
<rbuckton (PTO: 7/5 - 7/16)>
Yeah, that seems to be the case. There are only three exact matches for $_ and they are either var $_ = or window.$_ = , and the window.$_ = case reports a deprecation warning.
20:10
<rbuckton (PTO: 7/5 - 7/16)>
yield was probably more common than await, since yield can also be used a noun in agriculture and finance
20:11
<rbuckton (PTO: 7/5 - 7/16)>
I don't know if there were any actual statistics collected for either case, however.
20:13
<rbuckton (PTO: 7/5 - 7/16)>
yield though ran into a case where Mozilla shipped generators unflagged prior to ES2015 without a * marker on the function, so that may have curtailed use somewhat.
20:13
<rbuckton (PTO: 7/5 - 7/16)>
(if memory serves correctly)
20:17
<jschoi>
The usage statistics are compelling that $_ is better than $$. I have been convinced.
20:17
<rbuckton (PTO: 7/5 - 7/16)>
Disregard my earlier comment about counts. I refined my search to get around the "too exhaustive warning" and found more instances of $_ than initially reported.
20:17
<jschoi>
Oh, okay, in that case, never mind. 🥲
20:17
<rbuckton (PTO: 7/5 - 7/16)>

cs won't give me accurate counts however, though it seems most cases are either:

var $_ = function ...;
const $_ = ...;
class $_ { ... }
function $_ {}
20:18
<rbuckton (PTO: 7/5 - 7/16)>
I'd have to find a different way to query to get more accurate counts from GitHub's corpus of OSS projects.
20:19
<jschoi>
I wonder why they use $_, hmm. I guess it’s still true that $$ is still often (?) used to mean document.querySelectorAll, probably as an adjunct to jQuery or whatever.
20:19
<jschoi>
I would support an identifier as the topic reference only if the idea is that we would be blessing a new (contextual) keyword, and that, from now on, developers should never use the keyword as an ordinary variable. Just like await and yield. This is why I don’t think it is acceptable.
20:20
<jschoi>
When I see await and yield, I don’t have to think, “Is this a variable or a keyword?” Because nobody uses them as ordinary variables. This is very much not the case for it.
20:20
<jschoi>
If we blessed, say, $_ into the topic reference as a contextual keyword, then I would expect linters to ban $_ as an ordinary variable…just like how (I think?) they do with await and yield.
20:21
<rbuckton (PTO: 7/5 - 7/16)>
I think there are others on the committee that may have a specific tool for querying such usage, but I do know know offhand what that is.
20:21
<jschoi>
Gzemnid?
20:31
<rbuckton (PTO: 7/5 - 7/16)>
If that's it, I'm not sure what versions of node it works with because it won't install on my machine using a recent version of node :/
20:34
<jschoi>
No need to install anything (maybe except lz4). You can download a dataset (last updated in 2019) from https://gzemnid.nodejs.org/datasets/out.2019-06-04/. Then use the search.topcode.sh script (download from the same directory).
21:10
<rbuckton (PTO: 7/5 - 7/16)>
$ ./scripts/search.topcode.sh '[ .(\n]\$\$[ .(\n]' | wc -l
27831
$ ./scripts/search.topcode.sh '[ .(\n]\$\_[ .(\n]' | wc -l
530
21:11
<rbuckton (PTO: 7/5 - 7/16)>
Very rough regexp to avoid $$ or $_ in the middle of an identifier.
21:30
<rbuckton (PTO: 7/5 - 7/16)>
still a number of false positives from comments like // $_ though
21:40
<jschoi>
Nice. We used | grep -E --invert-match '//.*whatever' when we tried to analyze Gzemnid for .bind and .call.
22:13
<rbuckton (PTO: 7/5 - 7/16)>

Quite a few false positives due to string literals and comments and this doesn't handle unicode identifiers, but here's an updated query:

$ ./scripts/search.topcode.sh '[^$_\\[:alnum:]](\$\$)[^$_[:alnum:]]' | wc -l
38639
$ ./scripts/search.topcode.sh '[^$_\\[:alnum:]](\$\_)[^$_[:alnum:]]' | wc -l
629
22:14
<rbuckton (PTO: 7/5 - 7/16)>
It's too bad \P{ID_Continue} doesn't work in grep
22:39
<Richard Gibson>
I mildly prefer $$ to $_ because: $_ is already being used in some contexts like browser inspectors (although admittedly this is a niche case; there might be other extant uses), $$ is indeed easier to type, and $_ is uglier to me than $$. As you know, the fact that $_ but not $$ is valid syntax for variables in Bash/Perl/Ruby, so $_’s use is an incident of those languages’ peculiarities.
But this is a mild preference.
$$ is also used in browser developer tools: https://developer.chrome.com/docs/devtools/console/utilities/#querySelectorAll-function