2022-07-07 [10:32:39.0232] Yeah, TabAtkins, thanks for continuing to engage with him and others—I’ve been really busy myself, so I haven’t been able to work much on outreach or updates myself. 😔 [13:25:11.0750] And now I'm back to just closing issue threads because the participants refuse to stay on topic and instead keep relitigating the core question. :/ [13:26:02.0737] Should have done that one weeks ago, but I know Kevin personally and wanted to keep things friendly, but good *lord* I do not have time nor interest to engage in dueling essays where every point was brought up and addressed last year. [13:29:00.0837] (if he has made novel points I missed them in the screenfuls of text that each post of his produces) [13:29:32.0997] Insofar that we have already addressed many points of argument that people keep perseverating over, we should add an FAQ section or an FAQ document that summarizes positions, so we could simply point to them every time something gets brought up again. I’ve meant to do this for a year now, but I just haven’t had time. My apologies about this—maybe if I had done so earlier, we would have had you deal with a few less circular threads. [13:29:45.0390] I doubt it. ^_^ [13:33:52.0041] at least stare decisis have entered people's vocabularies recently [13:34:21.0454] ah yes, the "stand your ground" rule [13:34:33.0866] though i guess in this case it's more like res judicata than stare decisis [13:34:40.0159] * though i guess in this case it's more like res judicata than stare decisis [13:47:37.0559] “Stare decisis” (n.): The act of staring decisively at each other, without budging. [14:20:27.0031] this has truly been a depressing proposal, sociologically speaking [14:22:39.0842] huh, for some reason I can't hide Kevin's latest response in https://github.com/tc39/proposal-pipeline-operator/issues/238#issuecomment-1178231937 (but could hide his earlier ones) [15:09:32.0938] TabAtkins: sometimes i see no "hide" link present, especially when the anchor link points to that specific comment - i usually click the timestamp of another comment and hard-refresh [15:11:32.0129] Ah, that was indeed the problem. How confusing. Thanks! [15:22:39.0271] Have we ever tried to quantify how much of the ecosystem prefers Hack-style vs. F#-style? It's unfortunate that much of the early negative response was so vitrolic, but I still wonder if Hack-style was the right direction. This proposal constantly feels like it's being pushed uphill. [15:26:58.0909] do you plan to hire Pew? [15:28:00.0903] No, no budget for that [15:33:20.0793] For what it’s worth, I view reconciliation with call-this syntax to be a much greater obstacle to pipe operator compared to its syntax particulars like Hack/F#—or the choice of the topic, for that matter.
(That is, Jordan’s prior condition to pipe’s advancement to Stage 2 that a this-binding-or-calling syntax also “eventually” advance, and the fact that we have some strong opposition to any such this-binding/calling syntax.)
This is one of the two topics that the pipe incubator was chartered to discuss, and we might have some time this plenary to discuss it. But if pipe fails to ever reach Stage 4, it’s going to be because of that critical issue. [15:33:42.0026] > <@rbuckton:matrix.org> Have we ever tried to quantify how much of the ecosystem prefers Hack-style vs. F#-style? It's unfortunate that much of the early negative response was so vitrolic, but I still wonder if Hack-style was the right direction. This proposal constantly feels like it's being pushed uphill. * For what it’s worth, I view reconciliation with call-this syntax to be a much greater obstacle to pipe operator compared to its syntax particulars like Hack/F#—or the choice of the topic, for that matter.
(That is, Jordan’s prior condition to pipe’s advancement to Stage 2 that a this-binding-or-calling syntax also “eventually” advance, and the fact that we have some strong opposition to any such this-binding/calling syntax.)
This is one of the two topics that the pipe incubator was chartered to discuss, and we might have some time this plenary to discuss it. But if pipe fails to ever reach Stage 4, it’s going to be because of that critical issue. [15:34:06.0966] “The default is that neither proposal advances, and I’m fine with that,” so to speak. Well, I can sympathize with gatekeeping [what’s left of] the core language’s simplicity, even if I shed one tear doing so. :’) [15:34:40.0697] * “The default is that neither proposal advances, and I’m fine with that,” so to speak. Well, I can sympathize with gatekeeping [what’s left of] the core language’s simplicity, even if I shed one tear doing so. :’) [15:35:36.0171] I am still, and probably always be, in favor of F#-style + PFA, even with the limitations regarding yield and await. [15:37:02.0585] * That is to say, Jordan will probably always block Stage 4 for pipe unless call-this or something like it reaches Stage 3 or 4, as he essentially warned when it reached Stage 2 way back c. 2017. And (someone else’s words) “the default is that neither proposal advances, and I’m fine with that,” so to speak. I suppose I can sympathize with gatekeeping [what’s left of] the core language’s simplicity, even if I shed one tear doing so. :’) [15:40:25.0270] I can certainly sympathize, though my perspective is colored by my Clojure heritage. Speaking of which, there’s always Elixir style. Or Clojure’s operator-all-the-pipes-they’re-all-just-macros style (->, ->>, as->, cond->, etc.), heh. [15:40:35.0341] * I can certainly sympathize, though my perspective is colored by my Clojure heritage. Speaking of which, there’s always Elixir style. Or Clojure’s operator-all-the-pipes-they’re-all-just-macros style (->, ->>, as->, cond->, etc.), heh. [15:56:38.0902] > <@jschoi:matrix.org> I can certainly sympathize, though my perspective is colored by my Clojure heritage. Speaking of which, there’s always Elixir style. Or Clojure’s operator-all-the-pipes-they’re-all-just-macros style (->, ->>, as->, cond->, etc.), heh. Strongly imposed to Elixir style implicit parameter injection, it just adds more confusion over JS's existing implicit `this`. [15:58:26.0183] At least both Hack-style and F#-style are explicit. Hack-style with a topic, F#-style with `x |> F` meaning `F(x)` (plus PFA explicit placeholders). [16:00:08.0272] And I still feel if you're using `|>` to do simple expressions like `a + b`, you're holding it wrong. Its the wrong tool for the job. [16:01:15.0286] Yeah, I agree about Elixir style. Anyways, all of these things are different ways to deal with the dichotomy between unary functional languages and n-ary functional languages. Something like a unary–n-ary functional impedance mismatch, to varying degrees. [16:01:20.0809] * Yeah, I agree about Elixir style. Anyways, all of these things are different ways to deal with the dichotomy between unary functional languages and n-ary functional languages. Something like a unary–n-ary functional impedance mismatch, to varying degrees. [16:02:19.0086] i suspect pipeline is the right tool for the job any time you have something complex to pass into a function, or a function call's return value to pass into a function. [16:04:37.0360] > <@ljharb:matrix.org> i suspect pipeline is the right tool for the job any time you have something complex to pass into a function, or a function call's return value to pass into a function. That's exactly my point. Piping through functions is the right use. The contrived `x |> % + 1` examples are the ones I think are a poor use. [16:05:07.0864] sure. but i don't think those are at all the only ones that support hack [16:05:45.0586] I'd much rather have `do {}` or a `let..in` syntax for those cases. [16:06:03.0177] personally i have a bunch of examples that would work equally well in either style, and a bunch of examples where hack avoids creating a bunch of extra arrow functions, and close to zero examples (but nonzero) where F# is simpler [16:10:46.0703] I think `complexExpr |> % + 1` is contrived insofar that you could always replace it with `complexExpr + 1`. It’s because `+` is a fairly loose operator. In contrast, `complexExpr |> % ** 2` may not be so contrived, since otherwise it probably would have to be `(complexExpr) ** 2` with parentheses—and now imagine tacking on more and more (syntactically tight) operations… [16:17:18.0363] Function calls are a very syntactically tight operation, involving circumflex operators. It is for that reason that it is quite inconvenient to write and to read deeply nested function calls. But this is also generalizable to deeply nested “syntactically tight operations”, of which function calls are a subset. + expressions don’t fit as well in that set, but there are other ones that do. (And there’s also prefix operations like await and -—even though they are syntactically loose, they also mess with writing and reading when applied to deeply nested expressions due to reading order switching between LTR and RTL.) *Both* F# pipes and Hack pipes try to solve *all* these problems, in their own ways (e.g., `veryDeeplyNestedExpression |> negate` vs. `veryDeeplyNestedExpression |> -%`. [16:19:18.0870] * Function calls are a very syntactically tight operation, involving circumflex operators. It is for that reason that it is quite inconvenient to write and to read deeply nested function calls. But this is also generalizable to deeply nested “syntactically tight operations”, of which function calls are a subset. + expressions don’t fit as well in that set, but there are other ones that do. (And there’s also prefix operations like await and -—even though they are syntactically loose, they also mess with writing and reading when applied to deeply nested expressions due to reading order switching between LTR and RTL.) *Both* F# pipes and Hack pipes try to solve *all* these problems, in their own ways (e.g., `veryDeeplyNestedExpression |> negate` vs. `veryDeeplyNestedExpression |> -%`. 2022-07-08 [18:48:52.0922] (oh man I know that was just a typo but the idea of a language where a combining circumflex would serve as an operator is quite amusing to me) 2022-07-09 [19:38:25.0282] Every time someone says "non-function use-cases are contrived" I look back at all the times I've gone "fuck, I wish I had pipeline right now, this is kinda annoying to write" and how they're a pretty substantial mix of functions and operators and just go.... really? [19:39:14.0940] I fundamentally do not understand how this assertion can be made when I know for a fact how many times I, personally, want non-functions. [19:42:42.0391] > <@ljharb:matrix.org> personally i have a bunch of examples that would work equally well in either style, and a bunch of examples where hack avoids creating a bunch of extra arrow functions, and close to zero examples (but nonzero) where F# is simpler Yes, this is my experience precisely. I often want to pipe into functions (sometimes unary, sometimes not; PFA would address the latter cases), but I also often want to linearize other things (mostly math stuff, calling methods on something complex, and of course `await` every. single. fucking. time). [10:04:45.0583] I frequently want to construct e.g. a Map or Set, which currently requires `new` (as in `… |> (entries => new Map(entries))` if tacit/point-free or `… |> (new Map(^))` if not) [10:24:07.0653] Did we ever consider `*` as a topic token? `f() |> g({ x: * })`. I don’t remember why `*` was disqualified, if it was at all. (Otherwise, the top runner is `^^`, given `@`’s recent problems found by WH.) [10:24:30.0254] Is it because of yield *? (This is such a rare case that we could require it to be `yield (*)`.) [10:24:58.0058] * Is it because of yield *? (This is such a rare case that we could require it to be `yield (*)`.) [10:25:07.0397] * Is it because of `yield *`? (This is such a rare case that we could require it to be `yield (*)`.) [10:27:01.0089] Or maybe it’s because of `**`…`f() |> g(**2)` is terrible but we would probably require separation between topic `*` and binary `*`/`**` anyway, just from the tokenization perspective. I probably wouldn’t be a big deal to make people use a space to disambiguate the tokenization here. [10:27:17.0333] * Or maybe it’s because of **…f() |> g(***2) is terrible but we would probably require separation between topic * and binary */** anyway, just from the tokenization perspective. It’s not a big ask to make people use a space to disambiguate the tokenization here. [10:27:47.0894] * Or maybe it’s because of `**`…`f() |> g(**2)` is terrible but we would probably require separation between topic `*` and binary `*`/`**` anyway, just from the tokenization perspective. I probably wouldn’t be a big deal to make people use a space to disambiguate the tokenization here. 2022-07-10 [10:51:22.0305] There was an interesting discussion in the last TC39/JavaScript Tools meeting about how pipeline was more statically analyzable by bundlers as a means of inlining and optimizing. I do wonder about the statements from implementers that F#-style couldn't be optimized. I definitely believe that F#+PFA could have been optimized to reduce actual function allocations. i.e., `x |> f~(?)` would have had no more overhead than `x |> f(%)`. 2022-07-11 [18:44:54.0303] Could we, perhaps, appease the functional programming folks by using `|>` for Hack pipes, `||>` for F# pipes, and `|||>` for function composition? i.e., - `x |> expr` - First-order pipelining, i.e. evaluating expressions (i.e., "evaluate pipeline" or "expression pipeline"). Has a topic. - `x ||> F` - Second-order pipelining, i.e. calling unary functions (i.e., "call pipeline" or "function pipeline"). Does not have a topic. - `F |||> G` - Third-order pipelining, i.e. composition of unary functions (i.e., "compose pipeline"). Does not have a topic. This makes some sense as far as first-order vs. higher-order pipeline: ``` // first-order x |> F(%) |> G(%) // second-order x ||> F ||> G // third-order // NOTE: this is backwards from f . g === g(f(x)), but perhaps we // could introduce a "back pipe" `<|||` as a true point/compose operator x ||> (F |||> G) x |> (F |||> G)(%) ``` [18:46:25.0044] That would not only cover the FP crowd but also the data science crowd. [18:48:34.0886] And if we wanted true point/compose, we could pair it with "back pipes" like in F#: ``` G(%) <| F(%) <| x // trickier to parse though G <|| F <|| x (G <||| F) <|| x ``` [18:50:06.0930] The back-pipe variant has similarities to decorator application as well: ``` class C { @F @G method() {} } F <|| G <|| function () {} ``` [19:04:03.0598] Then there's something for everyone, and while there might be some that ask "But can't we use `|>` for the F# case?" we could say that `|>` means "first-order", `||>` means "second-order" and `|||>` means "third-order" as a heuristic roughly based in first-order vs. higher-order logic. [19:13:37.0483] For example, suppose we had my [functional operators](https://github.com/rbuckton/proposal-functional-operators) and PFA proposals: ``` a * b + c a {*} b {+} c plus(times(a, b), c) // first-order a |> % * b |> % + c a |> % {*} b |> % {+} c a |> times(a, b) |> plus(%, c) // second-order a ||> {*} b ||> {+} c a ||> times~(?, b) ||> plus~(?, c) // third-order a ||> ({*} b |||> {+} c) a ||> (times~(?, b) |||> plus~(?, c)) ``` [19:14:42.0865] * For example, suppose we had my [functional operators](https://github.com/rbuckton/proposal-functional-operators) and PFA proposals: ``` a * b + c a {*} b {+} c plus(times(a, b), c) // first-order a |> % * b |> % + c a |> % {*} b |> % {+} c a |> times(a, b) |> plus(%, c) // second-order a ||> {*} b ||> {+} c a ||> times~(?, b) ||> plus~(?, c) // third-order a ||> ({*} b |||> {+} c) a ||> (times~(?, b) |||> plus~(?, c)) ``` [19:43:34.0688] > <@jschoi:matrix.org> Did we ever consider `*` as a topic token? `f() |> g({ x: * })`. I don’t remember why `*` was disqualified, if it was at all. > > (Otherwise, the top runner is `^^`, given `@`’s recent problems found by WH.) Binary operators are all problematic, and common ones like `*` are bad separately bc it's not unlikely that authors will multiply the topic by something. [19:44:12.0145] But yeah, `*` vs `**` and `yield*` all make `*` even worse, specifically. [19:50:45.0138] rbuckton (PTO: 7/5 - 7/16): Putting aside that I'm very confident a second pipe won't make it thru committee (the majority of the benefit of pipeline is already granted by the first one), I've no problem with pursuing tacit pipes in the future, so long as they don't block *this* proposal (either by trying to claim syntax, or by getting bundled into this proposal as a package). [19:56:04.0541] It might have more credence if its promoted as a compromise for FP/Data Science, and that it may have less impact on performance if a first-order `|>` already exists, i.e.: The folks that need it will use it, as they would have been using unary functions anyways (so perf impact would be equivalent), but general use cases could lean on `|>` instead. Linters could, in theory, point users to using `|>` over `||>` (or `|||>`) when their usage would benefit from simplification. [19:57:11.0709] And it would help to include, rather than alienate, existing FP libraries in the ecosystem. [20:01:45.0070] * And it would be a way to include, rather than alienate, existing FP libraries in the ecosystem. [20:05:14.0372] while any empirical data would obviously confirm that `*` is more widely used than `^`, I will never not hate that `^^` is in the running just because we consider `^` uncommon in practice [20:05:50.0065] I've said that here before but I guess I should say it more publicly/formally [20:18:01.0120] Like I said, I've no problem with it *so long as it doesn't do anything to block this one*; promoting it as a compromise solution implies that it's a package with the current pipeline and will only hurt our chances of getting either thru. [05:38:55.0326] > <@tabatkins:matrix.org> Binary operators are all problematic, and common ones like `*` are bad separately bc it's not unlikely that authors will multiply the topic by something. Yeah, agreed, but I think that requiring separation between the topic and binary `*`/`**` might not be a big cost. I suspect maybe >90% of uses of pipe will be with function calls or object/array literals `f() |> g([*], 0), and it may be worth optimizing for those cases, rather than for `f() |> * ** 2`. And even `f() |> * ** 2` isn’t that unreadable. It’s worth at least considering, since it probably is basically the only single-character token left. [05:39:43.0785] > <@rkirsling:matrix.org> while any empirical data would obviously confirm that `*` is more widely used than `^`, I will never not hate that `^^` is in the running just because we consider `^` uncommon in practice Disliking `^^` then, are you? 🙂 [05:40:21.0610] > <@rkirsling:matrix.org> while any empirical data would obviously confirm that `*` is more widely used than `^`, I will never not hate that `^^` is in the running just because we consider `^` uncommon in practice * You dislike `^^` then, is that right? If so, I’ll add it to the table. 🙂 [05:42:01.0831] * You dislike `^^` then, is that right, Ross? If so, I’ll add it to the wiki page’s Table of Opinions. 🙂 [05:43:44.0435] > <@tabatkins:matrix.org> Binary operators are all problematic, and common ones like `*` are bad separately bc it's not unlikely that authors will multiply the topic by something. * Yeah, agreed, but I think that requiring separation between the topic and binary `*`/`**` might not be a big cost. I suspect maybe >90% of uses of pipe will be with function calls or object/array/tuple/record literals `f() |> g(#[*], 0)`, and it may be worth optimizing readability for those cases, rather than for `f() |> * ** 2`. And even `f() |> * ** 2` isn’t that unreadable, I think. 
It’s worth at least considering, since it probably is basically the only single-character token left. [06:02:09.0639] I'm presuming `~` was discussed? It's at least only a unary operator and not binary. And uncommon [06:02:16.0868] * I'm presuming `~` was discussed? It's at least only a unary operator and not binary. And uncommon [06:03:08.0868] I guess `~(1)` is visually ambiguous [06:03:54.0860] * I guess `~(1)` is visually ambiguous [06:06:55.0554] `~` is nice and we haven’t discussed it properly either. `f() |> g(#[~], 0) |> ~(~)`, hmm… PFA syntax would use `~`. But `f() |> (~)~(0, ?)` would be quite rare! [06:08:08.0750] (I’ve added a breakout session for topic tokens to the plenary although we might not have time.) [06:08:53.0190] To call it would have to do something like: `(~)(arg)` [06:09:52.0354] Oh yeah. Which might not be that bad…? Which is worse: `f() |> * ** 2` `f() |> (~)(0)` [06:10:51.0037] * Oh yeah. Which might not be that bad…? Which is worse (or at least which would be more common):
`f() |> * ** 2`
`f() |> (~)(2)` [06:11:37.0160] could be a hazard if someone writes `~(arg)` and expects a function call. If arg can be converted to a number it won’t throw either [06:12:11.0517] but again, maybe that’s OK for the benefit of a single character token [06:13:18.0337] At least it will throw if it’s the only expected use of topic in the pipe body.
`f() |> ~(2)` is a SyntaxError: “Pipe body contains no topic.” [06:13:57.0413] > <@aclaymore:matrix.org> could be a hazard if someone writes `~(arg)` and expects a function call. If arg can be converted to a number it won’t throw either * At least it will throw if it’s the only expected use of topic in the pipe body.
`f() |> ~(2)` is a SyntaxError: “Pipe body contains no topic.” [06:16:05.0411] * At least it will throw if it’s the only expected use of topic in the pipe body.
 `f() |> ~(2)` would be a SyntaxError: “Pipe body contains no topic.” (`f() |> #[~(2), ~ + 1]` would not be a SyntaxError, but is that situation going to be common? Hmm.) [06:19:09.0123] Ah yes. I had completely forgotten about "it will throw if it’s the only expected use of topic in the pipe body." [06:52:55.0128] `* * * ** *` [06:54:45.0158] That example makes my eyes feel like they’re bleeding, but at least that’s hardly ever going to happen. R-Right? [06:55:14.0352] I'm just saying, math is a lot more common than binary xor 😅 [06:56:30.0876] Yeah, true. Though…I think was RBN or WH or someone who said that we can always come up with contrived examples, like `#[#[#[#[##, this.#blah, #{#[this.#a, this.#b, ##]}], ##]]]`. The key is whether an example is going to be common enough to be a concern. Frequency × impact per occurrence = expected impact. [06:56:58.0348] It’s true that the frequency of binary `*` and `**` > the frequency of prefix `~`… [06:57:47.0789] …Will the frequency of calling-a-topic-as-a-function be comparable to the frequency of binary `*` and `**`? It is tough to say. [07:47:18.0353] Right, my big concern is that multiplication is pretty common (and I've wanted to use pipe in precisely a spot where I'd multiply the topic). Xoring the topic, or calling as a function, are both way less common, yeah. (And outside of lambda calculus, calling the topic as a function *and* using the topic as an argument would be incredibly rare, so avoiding the early error will be super uncommon.) [07:47:50.0291] I also don't feel good about the `yield*` case [07:48:51.0429] Sounds reasonable! I think I agree. I will add these opinions to the wiki table when I can. [07:50:52.0447] * Sounds reasonable! I think I agree that topic `~` is probably better than topic `*`. I will add these opinions to the wiki table when I can. [07:52:01.0016] * Sounds reasonable! I think I agree that topic `~` is probably better than topic `*`. (And it should still work with PFA syntax: `f() |> g~(~, 0)`.) I will add these opinions to the wiki table when I can. [07:55:26.0838] * `\* \* \* \*\* \*\` [07:55:40.0163] * `* * * ** *` [14:17:06.0511] yeah, I think I'd feel less bad about `~` [14:17:54.0454] to be clear, I'm not blocking wrt `^^`, it just makes me slightly sad (...which is ironic when viewed as kaomoji lol) [14:24:50.0809] I say "slightly" because re-noticing in the wiki table that empirical rarity is _not_ the only justification for `^^` makes me feel less awful [14:30:11.0561] I’m not sure why I thought `*` would be any different from `% ` and `^`, which Shu and others are against because they would require InputElementDiv/InputElementRegExp–style contextuality in the lexer. `*` is not different from `%` and `^`; it suffers from the same problem, and so `*` is out. I don’t think `~` suffers from the same problem? I left a comment with some examples but I’m not 100% sure. [14:30:53.0096] * I’m not sure why I thought `*` would be any different from `% ` and `^`, which Shu and others are against because they would require InputElementDiv/InputElementRegExp–style contextuality in the lexer. `*` is not different from `%` and `^`; it suffers from the same problem, and so `*` is out. I don’t think `~` suffers from the same problem? I left a comment with some examples but I’m not 100% sure. [15:11:41.0024] Apologies, I thought you'd already noticed that - I referenced the contextuality problem indirectly in my first response to `*`. 2022-07-13 [06:42:16.0663] I think the `f() |> ~ + ~` case is unfortunate enough to exclude ~ as topic, but `f() |> ~~ + ~~` should work, right? `^^`, `~~`, `%%`, `@@`, `##`. [06:43:53.0420] * I think the `f() |> ~ + ~` case is unfortunate enough to exclude ~ as topic, but `f() |> ~~ + ~~` should work, right? `^^`, `~~`, `%%`, `@@`, `##`. [07:13:27.0310] Isn't `~~(n) ` still valid JS? I don't think doubling is a solution. [09:04:52.0641] You’re right; no doubled prefixes allowed. [09:54:24.0847] Yeah double binaries is good, double unaries isn't. [10:41:18.0623] `#~` though? ;) [11:26:29.0970] 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. [11:27:14.0559] * 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. [11:28:13.0697] (especially since I already wrote one 7 years ago for TS decorators while exploring the feature, though I never published it) [12:09:56.0333] presumably 'banning' unary `~` in a pipe body is a very unpopular opinion [12:10:26.0334] * presumably 'banning' unary `~` in a pipe body is a very unpopular opinion. (I'm a ^^ fan, but just curious) [12:16:25.0516] what's interesting about unaries though is that they don't warrant a separate pipe [12:16:51.0084] Yes. TS compiler wants to use pipes and we internally use bitmasks, so we would be strongly against banning `~` or `^` inside a pipe [12:17:20.0837] i.e. you can do `~~x |> foo(#)` or `y |> ~~bar(#)`, there's no need for `|> ~~#` [12:17:42.0634] * i.e. you can do `~~x |> foo(#)` or `y |> ~~bar(#)`, there's no need for `|> ~~#` [12:27:18.0282] 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: ```js 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 `~`). [12:29:12.0832] I much prefer the readability of an identifier here: ```js 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 ``` [12:32:39.0928] Though we're much more likely to see the topic used with `~` in less ambiguous cases such as in the call to `setEmitFlags` below: ```js return factory.createBinaryExpression(...) |> setOriginalNode(~, node) |> setSourceMapRange(~, { pos: ..., end: ... }) |> setEmitFlags(~, getEmitFlags(node) & ~EmitFlags.NoComments); ``` [12:40:19.0606] 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. [12:40:28.0533] * 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. [12:40:35.0518] * 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: ```js 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 `~`). [12:40:53.0206] * I much prefer the readability of an identifier here: ```js 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 ``` [12:42:02.0015] 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) => { ... })` [12:42:03.0802] ```js binarySearch(array, value) |> ($$ >= 0 ? array[$$] : array[~$$ + 1]); binarySearch(array, value) |> (__ >= 0 ? array[__] : array[~__ + 1]); ``` [12:42:13.0347] Right, that makes sense. [12:43:23.0725] 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 `$_`. [12:45:47.0348] Plus editors can easily offer a completion for `$_` on the right of a `|>`, so its more likely someone just does `$` [12:51:01.0995] yeah I've expressed before that something with `_` would feel the most "obvious" to me [12:51:04.0695] 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, `$_` is valid syntax for variables in Bash/Perl/Ruby but `$$` is not. But this is a mild preference. [12:51:08.0172] * yeah I've expressed before that something with `_` would feel the most "obvious" to me [12:51:11.0009] 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. [12:51:11.0666] * 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, `$_` is valid syntax for variables in Bash/Perl/Ruby but `$$` is not. But this is a mild preference. [12:52:28.0711] `$_` 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. [12:53:44.0614] * `$_` 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. [12:55:26.0692] 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. [12:55:33.0123] * 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. [13:02:02.0475] 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. [13:02:52.0690] * 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.~~ I need to recheck this due to an error in the query, so this may not be accurate... [13:03:00.0169] * 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.~ I need to recheck this due to an error in the query, so this may not be accurate... [13:04:05.0556] GitHub is telling me results are not exhaustive, but still only provides me with 18 total matches. [13:04:58.0019] * 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. [13:05:14.0273] Does `$_` get set while in the expression [13:05:24.0921] I thought it was only done at statement positions [13:06:59.0283] * 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, some are substring matches and don't count. [13:07:38.0627] * 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. [13:07:56.0483] Excellent data, thank you. [13:08:07.0536] * Excellent data, thank you. [13:08:51.0712] 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. [13:08:58.0994] 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. [13:09:11.0123] * 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. [13:10:37.0443] `yield` was probably more common than `await`, since `yield` can also be used a noun in agriculture and finance [13:11:19.0601] I don't know if there were any actual statistics collected for either case, however. [13:13:00.0152] * 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. [13:13:04.0954] `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. [13:13:26.0194] (if memory serves correctly) [13:17:00.0288] The usage statistics are compelling that `$_` is better than `$$`. I have been convinced. [13:17:00.0613] 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. [13:17:08.0936] Oh, okay, in that case, never mind. 🥲 [13:17:25.0096] * Oh, okay, in that case, never mind. 🥲 [13:17:59.0028] cs won't give me accurate counts however, though it seems most cases are either: ```js var $_ = function ...; const $_ = ...; class $_ { ... } function $_ {} ``` [13:18:35.0196] I'd have to find a different way to query to get more accurate counts from GitHub's corpus of OSS projects. [13:19:02.0968] 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. [13:19:32.0412] 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. [13:20:23.0868] 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`. [13:20:24.0326] 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`. [13:20:49.0726] * 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. [13:21:08.0817] * 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 might do with `await` and `yield`. [13:21:11.0655] 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. [13:21:13.0714] * 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`. [13:21:26.0919] Gzemnid? [13:31:09.0849] 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 :/ [13:34:15.0109] 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). [14:10:51.0600] ```sh $ ./scripts/search.topcode.sh '[ .(\n]\$\$[ .(\n]' | wc -l 27831 $ ./scripts/search.topcode.sh '[ .(\n]\$\_[ .(\n]' | wc -l 530 ``` [14:10:57.0088] * ```sh $ ./scripts/search.topcode.sh '[ .(\n]\$\$[ .(\n]' | wc -l 27831 $ ./scripts/search.topcode.sh '[ .(\n]\$\_[ .(\n]' | wc -l 530 ``` [14:11:21.0363] Very rough regexp to avoid $$ or $_ in the middle of an identifier. [14:30:19.0879] still a number of false positives from comments like `// $_` though [14:40:50.0883] Nice. We used `| grep -E --invert-match '//.*whatever'` when we tried to analyze Gzemnid for `.bind` and `.call`. [14:40:58.0078] * Nice. We used `grep -E --invert-match '//.*whatever'` when we tried to analyze Gzemnid for `.bind` and `.call`. [14:41:33.0400] * Nice. We used `| grep -E --invert-match '//.*whatever'` when we tried to analyze Gzemnid for `.bind` and `.call`. [15:13:44.0707] Quite a few false positives due to string literals and comments and this doesn't handle unicode identifiers, but here's an updated query: ```sh $ ./scripts/search.topcode.sh '[^$_\\[:alnum:]](\$\$)[^$_[:alnum:]]' | wc -l 38639 $ ./scripts/search.topcode.sh '[^$_\\[:alnum:]](\$\_)[^$_[:alnum:]]' | wc -l 629 ``` [15:14:25.0018] It's too bad `\P{ID_Continue}` doesn't work in `grep` [15:39:32.0278] > <@jschoi:matrix.org> 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 2022-07-14 [17:01:13.0401] > <@rbuckton:matrix.org> It's too bad `\P{ID_Continue}` doesn't work in `grep` would you settle for GNU awk supporting `/[0-9A-Z_a-zªµ·ºÀ-ÖØ-ö ø-ˁˆ-ˑˠ-ˤˬˮ̀-ʹͶͷͺ-ͽͿΆ-Ί ΌΎ-ΡΣ-ϵϷ-ҁ҃-҇Ҋ-ԯԱ-Ֆՙՠ-ֈ֑-ׇֽֿׁׂׅׄ א-תׯ-ײؐ-ؚؠ-٩ٮ-ۓە-ۜ۟-۪ۨ-ۼ ۿܐ-݊ݍ-ޱ߀-ߵߺ߽ࠀ-࠭ࡀ-࡛ࡠ-ࡪ ࡰ-ࢇࢉ-ࢎ࢘-ࣣ࣡-ॣ०-९ॱ-ঃঅ-ঌ এঐও-নপ-রলশ-হ়-ৄেৈো-ৎৗ ড়ঢ়য়-ৣ০-ৱৼ৾ਁ-ਃਅ-ਊਏਐਓ-ਨ ਪ-ਰਲਲ਼ਵਸ਼ਸਹ਼ਾ-ੂੇੈੋ-੍ੑਖ਼-ੜ ਫ਼੦-ੵઁ-ઃઅ-ઍએ-ઑઓ-નપ-રલળ વ-હ઼-ૅે-ૉો-્ૐૠ-ૣ૦-૯ૹ-૿ଁ-ଃ ଅ-ଌଏଐଓ-ନପ-ରଲଳଵ-ହ଼-ୄେୈୋ-୍୕-ୗ ଡ଼ଢ଼ୟ-ୣ୦-୯ୱஂஃஅ-ஊஎ-ஐஒ-கங சஜஞடணதந-பம-ஹா-ூெ-ைொ-் ௐௗ௦-௯ఀ-ఌఎ-ఐఒ-నప-హ఼-ౄె-ైొ-్ౕౖ ౘ-ౚౝౠ-ౣ౦-౯ಀ-ಃಅ-ಌಎ-ಐಒ-ನ ಪ-ಳವ-ಹ಼-ೄೆ-ೈೊ-್ೕೖೝೞೠ-ೣ ೦-೯ೱೲഀ-ഌഎ-ഐഒ-ൄെ-ൈൊ-ൎൔ-ൗ ൟ-ൣ൦-൯ൺ-ൿඁ-ඃඅ-ඖක-නඳ-ර ලව-ෆ්ා-ුූෘ-ෟ෦-෯ෲෳก-ฺเ-๎ ๐-๙ກຂຄຆ-ຊຌ-ຣລວ-ຽເ-ໄໆ່-ໍ ໐-໙ໜ-ໟༀ༘༙༠-༩༹༵༷༾-ཇཉ-ཬཱ-྄྆-ྗྙ-ྼ࿆ က-၉ၐ-ႝႠ-ჅჇჍა-ჺჼ-ቈቊ-ቍቐ-ቖ ቘቚ-ቝበ-ኈኊ-ኍነ-ኰኲ-ኵኸ-ኾዀዂ-ዅ ወ-ዖዘ-ጐጒ-ጕጘ-ፚ፝-፟፩-፱ᎀ-ᎏ Ꭰ-Ᏽᏸ-ᏽᐁ-ᙬᙯ-ᙿᚁ-ᚚᚠ-ᛪᛮ-ᛸ ᜀ-᜕ᜟ-᜴ᝀ-ᝓᝠ-ᝬᝮ-ᝰᝲᝳក-៓ៗ ៜ៝០-៩᠐-᠙ᠠ-ᡸᢀ-ᢪᢰ-ᣵᤀ-ᤞᤠ-ᤫᤰ-᤻ ᥆-ᥭᥰ-ᥴᦀ-ᦫᦰ-ᧉ᧐-᧚ᨀ-ᨛᨠ-ᩞ᩠-᩿᩼-᪉ ᪐-᪙ᪧ᪰-᪽ᪿ-ᫎᬀ-ᭌ᭐-᭙᭫-᭳ᮀ-᯳ ᰀ-᰷᱀-᱉ᱍ-ᱽᲀ-ᲈᲐ-ᲺᲽ-Ჿ᳐-᳔᳒-ᳺ ᴀ-ἕἘ-Ἕἠ-ὅὈ-Ὅὐ-ὗὙὛὝὟ-ώ ᾀ-ᾴᾶ-ᾼιῂ-ῄῆ-ῌῐ-ΐῖ-Ίῠ-Ῥ ῲ-ῴῶ-ῼ‿⁀⁔ⁱⁿₐ-ₜ⃐-⃥⃜⃡-⃰ ℂℇℊ-ℓℕ℘-ℝℤΩℨK-ℹℼ-ℿⅅ-ⅉ ⅎⅠ-ↈⰀ-ⳤⳫ-ⳳⴀ-ⴥⴧⴭⴰ-ⵧⵯ⵿-ⶖ ⶠ-ⶦⶨ-ⶮⶰ-ⶶⶸ-ⶾⷀ-ⷆⷈ-ⷎⷐ-ⷖ ⷘ-ⷞⷠ-ⷿ々-〇〡-〯〱-〵〸-〼ぁ-ゖ゙-ゟ ァ-ヺー-ヿㄅ-ㄯㄱ-ㆎㆠ-ㆿㇰ-ㇿ㐀-䶿 一-ꒌꓐ-ꓽꔀ-ꘌꘐ-ꘫꙀ-꙯ꙴ-꙽ꙿ-꛱ ꜗ-ꜟꜢ-ꞈꞋ-ꟊꟐꟑꟓꟕ-ꟙꟲ-ꠧ꠬ꡀ-ꡳꢀ-ꣅ ꣐-꣙꣠-ꣷꣻꣽ-꤭ꤰ-꥓ꥠ-ꥼꦀ-꧀ꧏ-꧙ ꧠ-ꧾꨀ-ꨶꩀ-ꩍ꩐-꩙ꩠ-ꩶꩺ-ꫂꫛ-ꫝ ꫠ-ꫯꫲ-꫶ꬁ-ꬆꬉ-ꬎꬑ-ꬖꬠ-ꬦꬨ-ꬮ ꬰ-ꭚꭜ-ꭩꭰ-ꯪ꯬꯭꯰-꯹가-힣ힰ-ퟆퟋ-ퟻ 豈-舘並-龎ff-stﬓ-ﬗיִ-ﬨשׁ-זּטּ-לּ מּנּסּףּפּצּ-ﮱﯓ-ﴽﵐ-ﶏﶒ-ﷇﷰ-ﷻ︠-︯ ︳︴﹍-﹏ﹰ-ﹴﹶ-ﻼ０-９Ａ-Ｚ＿ａ-ｚ ｦ-ﾾￂ-ￇￊ-ￏￒ-ￗￚ-ￜ𐀀-𐀋𐀍-𐀦 𐀨-𐀺𐀼𐀽𐀿-𐁍𐁐-𐁝𐂀-𐃺𐅀-𐅴𐇽𐊀-𐊜 𐊠-𐋐𐋠𐌀-𐌟𐌭-𐍊𐍐-𐍺𐎀-𐎝𐎠-𐏃𐏈-𐏏 𐏑-𐏕𐐀-𐒝𐒠-𐒩𐒰-𐓓𐓘-𐓻𐔀-𐔧𐔰-𐕣 𐕰-𐕺𐕼-𐖊𐖌-𐖒𐖔𐖕𐖗-𐖡𐖣-𐖱𐖳-𐖹𐖻 𐖼𐘀-𐜶𐝀-𐝕𐝠-𐝧𐞀-𐞅𐞇-𐞰𐞲-𐞺𐠀-𐠅 𐠈𐠊-𐠵𐠷𐠸𐠼𐠿-𐡕𐡠-𐡶𐢀-𐢞𐣠-𐣲𐣴𐣵 𐤀-𐤕𐤠-𐤹𐦀-𐦷𐦾𐦿𐨀-𐨃𐨅𐨆𐨌-𐨓𐨕-𐨗 𐨙-𐨵𐨸-𐨿𐨺𐩠-𐩼𐪀-𐪜𐫀-𐫇𐫉-𐫦𐬀-𐬵 𐭀-𐭕𐭠-𐭲𐮀-𐮑𐰀-𐱈𐲀-𐲲𐳀-𐳲𐴀-𐴧 𐴰-𐴹𐺀-𐺩𐺫𐺬𐺰𐺱𐼀-𐼜𐼧𐼰-𐽐𐽰-𐾅𐾰-𐿄 𐿠-𐿶𑀀-𑁆𑁦-𑁵𑁿-𑂺𑃂𑃐-𑃨𑃰-𑃹𑄀-𑄴 𑄶-𑄿𑅄-𑅇𑅐-𑅳𑅶𑆀-𑇄𑇉-𑇌𑇎-𑇚𑇜𑈀-𑈑 𑈓-𑈷𑈾𑊀-𑊆𑊈𑊊-𑊍𑊏-𑊝𑊟-𑊨𑊰-𑋪𑋰-𑋹𑌀-𑌃 𑌅-𑌌𑌏𑌐𑌓-𑌨𑌪-𑌰𑌲𑌳𑌵-𑌹𑌻-𑍄𑍇𑍈𑍋-𑍍 𑍐𑍗𑍝-𑍣𑍦-𑍬𑍰-𑍴𑐀-𑑊𑑐-𑑙𑑞-𑑡𑒀-𑓅 𑓇𑓐-𑓙𑖀-𑖵𑖸-𑗀𑗘-𑗝𑘀-𑙀𑙄𑙐-𑙙𑚀-𑚸 𑛀-𑛉𑜀-𑜚𑜝-𑜫𑜰-𑜹𑝀-𑝆𑠀-𑠺𑢠-𑣩 𑣿-𑤆𑤉𑤌-𑤓𑤕𑤖𑤘-𑤵𑤷𑤸𑤻-𑥃𑥐-𑥙𑦠-𑦧 𑦪-𑧗𑧚-𑧡𑧣𑧤𑨀-𑨾𑩇𑩐-𑪙𑪝𑪰-𑫸𑰀-𑰈 𑰊-𑰶𑰸-𑱀𑱐-𑱙𑱲-𑲏𑲒-𑲧𑲩-𑲶𑴀-𑴆 𑴈𑴉𑴋-𑴶𑴺𑴼𑴽𑴿-𑵇𑵐-𑵙𑵠-𑵥𑵧𑵨𑵪-𑶎𑶐𑶑𑶓-𑶘 𑶠-𑶩𑻠-𑻶𑾰𒀀-𒎙𒐀-𒑮𒒀-𒕃𒾐-𒿰𓀀-𓐮 𔐀-𔙆𖠀-𖨸𖩀-𖩞𖩠-𖩩𖩰-𖪾𖫀-𖫉𖫐-𖫭𖫰-𖫴 𖬀-𖬶𖭀-𖭃𖭐-𖭙𖭣-𖭷𖭽-𖮏𖹀-𖹿𖼀-𖽊𖽏-𖾇𖾏-𖾟 𖿠𖿡𖿣𖿤𖿰𖿱𗀀-𘟷𘠀-𘳕𘴀-𘴈𚿰-𚿳𚿵-𚿻 𚿽𚿾𛀀-𛄢𛅐-𛅒𛅤-𛅧𛅰-𛋻𛰀-𛱪𛱰-𛱼𛲀-𛲈 𛲐-𛲙𛲝𛲞𜼀-𜼭𜼰-𜽆𝅥-𝅩𝅭-𝅲𝅻-𝆂𝆅-𝆋𝆪-𝆭𝉂-𝉄 𝐀-𝑔𝑖-𝒜𝒞𝒟𝒢𝒥𝒦𝒩-𝒬𝒮-𝒹𝒻𝒽-𝓃 𝓅-𝔅𝔇-𝔊𝔍-𝔔𝔖-𝔜𝔞-𝔹𝔻-𝔾𝕀-𝕄 𝕆𝕊-𝕐𝕒-𝚥𝚨-𝛀𝛂-𝛚𝛜-𝛺𝛼-𝜔𝜖-𝜴 𝜶-𝝎𝝐-𝝮𝝰-𝞈𝞊-𝞨𝞪-𝟂𝟄-𝟋𝟎-𝟿𝨀-𝨶𝨻-𝩬𝩵𝪄𝪛-𝪟𝪡-𝪯 𝼀-𝼞𞀀-𞀆𞀈-𞀘𞀛-𞀡𞀣𞀤𞀦-𞀪𞄀-𞄬𞄰-𞄽 𞅀-𞅉𞅎𞊐-𞊮𞋀-𞋹𞟠-𞟦𞟨-𞟫𞟭𞟮𞟰-𞟾 𞠀-𞣄𞣐-𞣖𞤀-𞥋𞥐-𞥙𞸀-𞸃𞸅-𞸟𞸡𞸢𞸤 𞸧𞸩-𞸲𞸴-𞸷𞸹𞸻𞹂𞹇𞹉𞹋𞹍-𞹏𞹑𞹒𞹔𞹗𞹙 𞹛𞹝𞹟𞹡𞹢𞹤𞹧-𞹪𞹬-𞹲𞹴-𞹷𞹹-𞹼𞹾𞺀-𞺉 𞺋-𞺛𞺡-𞺣𞺥-𞺩𞺫-𞺻🯰-🯹𠀀-𪛟𪜀-𫜸 𫝀-𫠝𫠠-𬺡𬺰-𮯠丽-𪘀𰀀-𱍊]/`? (pattern extracted from https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%5B%3AID_Continue%3A%5D%26%5B%3AVariation_Selector%3DNo%3A%5D%5D&g=&i= , which is technically incorrect because it excludes variation selectors but is otherwise good) [17:18:15.0705] what sorcery is this 2022-07-15 [05:25:29.0557] https://github.com/tc39/proposal-pipeline-operator/issues/217#issuecomment-1184910976
 > Edit: After it was clarified a more independent route of addressing my concerns can be feasible in the future, contrary to what I interpreted from strong stances expressed to me recently, I will bow out of these discussions indefinitely accordingly. My feedback regarding hack-style pipes impact on the functional-programming ecosystem can always be revisited whenever it next makes sense. *** I wonder to what this is referring; it was a pretty sudden change. [05:27:11.0929] The closest thing I can think of is my mentioning in https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1184950270 of the (small) possibility that Function.pipe and/or flow may be standardized, and that developers may use pipe/flow widely enough to warrant considering split-mix syntax again: `x |>> f |>> g |>> h |> [^^]`. [05:27:35.0342] * https://github.com/tc39/proposal-pipeline-operator/issues/217#issuecomment-1184910976 Edit: After it was clarified a more independent route of addressing my concerns can be feasible in the future, contrary to what I interpreted from strong stances expressed to me recently, I will bow out of these discussions indefinitely accordingly. My feedback regarding hack-style pipes impact on the functional-programming ecosystem can always be revisited whenever it next makes sense. I wonder to what this is referring; it was a pretty sudden change. [05:27:53.0154] * https://github.com/tc39/proposal-pipeline-operator/issues/217#issuecomment-1184910976
 > Edit: After it was clarified a more independent route of addressing my concerns can be feasible in the future, contrary to what I interpreted from strong stances expressed to me recently, I will bow out of these discussions indefinitely accordingly. My feedback regarding hack-style pipes impact on the functional-programming ecosystem can always be revisited whenever it next makes sense.
 I wonder to what this is referring; it was a pretty sudden change. [05:28:06.0667] * https://github.com/tc39/proposal-pipeline-operator/issues/217#issuecomment-1184910976
 > Edit: After it was clarified a more independent route of addressing my concerns can be feasible in the future, contrary to what I interpreted from strong stances expressed to me recently, I will bow out of these discussions indefinitely accordingly. My feedback regarding hack-style pipes impact on the functional-programming ecosystem can always be revisited whenever it next makes sense. *** I wonder to what this is referring; it was a pretty sudden change. [09:23:50.0176] Me and Shu talked with them privately [10:59:42.0005] any chance long essay-like comments were discouraged in these conversations? [11:09:22.0996] Very explicitly by me, yes. [11:09:39.0247] Like, ended the conversation with "don't do this" 2022-07-22 [17:57:00.0153] Hi all, jschoi invited me to this channel. I expressed the position during the meeting today that I think it would be worthwhile to continue exploring the space of API functions for method chaining. Although the Function.pipe proposal didn't reach Stage 1, I think it would be helpful to consider that direction in the context of the Pipeline proposal. The Pipeline champions considered "hack style" and "F# style" options for the pipeline proposal. I would like to see how the use cases would pan out with a third "API style" option. In other words, take the examples that motivate the pipeline syntax operator and show how they would work with Function.pipe, Function.pipeAsync, etc. [18:05:34.0083] Opened an issue: https://github.com/tc39/proposal-pipeline-operator/issues/273 [20:40:10.0815] Well, we could do an explicit comparison between topic pipe and pipe function in the explainer, but…chances are it’s not going to get very far. Pipe functions don’t pipe through n-arg function calls, array/object literals, or other things, other than await for pipeAsync. I never wanted to position the pipe/flow functions as anything other than an adjunct to the topic pipe. [20:43:29.0376] sffc: I had actually invited you to the room here, primarily, to let both you and HE Shi-Jun know that I’m planning to withdraw proposal-function-pipe-flow, and I wanted to offer championing that proposal to you before I archive it. Otherwise I would make it inactive, since I just don’t see any significant chance of it advancing in Committee given the feedback I got today. (My apologies for not making this clearer in my direct message!) [20:44:34.0609] (Also, a forewarning: that proposal-pipeline-operator’s issues can get very hot. We’ve had numerous CoC problems in that repository. 🥲) [20:44:59.0586] * sffc: I had actually invited you to the room here, primarily, to let both you and HE Shi-Jun know that I’m planning to withdraw proposal-function-pipe-flow, and I wanted to offer championing that proposal to you before I archive it. Otherwise I would make it inactive, since I just don’t see any significant chance of it advancing in Committee given the feedback I got today. (My apologies for not making this clearer in my direct message!) [20:49:36.0725] Anyways, regarding your new issue, it might be worth at least exploring the possibility of replacing operators with API. But I suspect it will not get far. For example, consider the explainer’s first example, from React: ```js console.log( chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' '))); ``` This is not an example where the pipe function would shine: ```js pipe( Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' '), $ => `$ ${%}`, $ => chalk.dim(%, 'node', args.join(' ')), $ => console.log(%), ); ``` The explainer’s “real-world code” section has many examples like this. [20:49:55.0459] * Anyways, regarding your new issue, it might be worth at least exploring the possibility of replacing operators with API. But I suspect it will not get far. For example, consider the explainer’s first example, from React: ```js console.log( chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' '))); ``` This is not an example where the pipe function would shine: ```js pipe( Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' '), $ => `$ ${%}`, $ => chalk.dim(%, 'node', args.join(' ')), $ => console.log(%), ); ``` The explainer’s “real-world code” section has many examples like this. [20:52:21.0599] (To be honest, I had wanted to wait until we decided exactly what we should do with proposal-function-pipe-flow—withdraw and archive versus transfer championing to you or Hax—before we announced that it failed to get Stage 1. Because there’s a good chance that people are going to get heated after the announcement, so I wanted to make sure we had a coordinated presentation to the community when we announced it. My apologies for not making this clear! Please do let me know if you want to champion proposal-function-pipe-flow or if you are fine with me withdrawing it.) [20:54:31.0229] * Anyways, regarding your new issue, it might be worth at least exploring the possibility of replacing operators with API. But I suspect it will not get far. For example, consider the explainer’s first example, from React: ```js console.log( chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' '))); ``` This is not an example where the pipe function would shine: ```js pipe( Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' '), $ => `$ ${%}`, $ => chalk.dim(%, 'node', args.join(' ')), console.log, ); ``` The explainer’s “real-world code” section has many examples like this. [20:55:22.0873] * Anyways, regarding your new issue, it might be worth at least exploring the possibility of replacing operators with API. But I suspect it will not get far. For example, consider the explainer’s first example, from React: ```js console.log( chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' '))); ``` This is not an example where the pipe function would shine compared to the pipe operator (especially given the encouraging-throwaway-closures concern from the engines): ```js pipe( Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' '), $ => `$ ${%}`, $ => chalk.dim(%, 'node', args.join(' ')), console.log, ); ``` The explainer’s “real-world code” section has many examples like this. [20:56:40.0123] * Anyways, regarding your new issue, it might be worth at least exploring the possibility of replacing operators with API. But I suspect it will not get far. For example, consider the explainer’s first example, from React: ```js console.log( chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' '))); ``` This is not an example where the pipe function would shine compared to the pipe operator (especially given the encouraging-throwaway-closures concern from the engines): ```js pipe( Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' '), v => `$ ${v}`, v => chalk.dim(v, 'node', args.join(' ')), console.log, ); ``` The explainer’s “real-world code” section has many examples like this. [20:57:17.0121] Hey! If you can post those examples on my issue that would be great to get the conversation started [20:58:42.0685] I'm not currently interested in championing the proposal. But maybe in the future. I think the best path is to finish the main pipeline proposal, get people to start using it, and then a year later, reopen this proposal. That's a multi-year process but things in TC39 take time :) [21:00:48.0042] Actually the iterator helpers proposal is a good example of that. Iterators have been around for several years now but they didn't come with a lot of standard library functions. So now the champions of iterator helpers can point to packages people have made to work around limitations in iterators in order to motivate their proposal. [21:00:48.0887] Sounds good; thank you! (I’ll give HE Shi-Jun a few days to also respond before I freeze the repository.) [21:01:55.0280] So basically, after pipeline gets users, you can point to pain points to motivate the Function.pipe proposal. [21:09:32.0821] sffc: Would you mind also getting rid of the mention, from your issue text, that proposal-function-pipe-flow failed to reach Stage 1? I want to publicly announce it myself first in the announcement thread in a few days. [21:10:13.0747] * sffc: Would you mind also getting rid of the mention, from your issue text, that proposal-function-pipe-flow failed to reach Stage 1? I want to publicly announce it myself first in the announcement thread in a few days, after I’ve determined what its fate is going to be. [21:12:01.0657] * sffc: Would you mind also getting rid of the mention, from your issue text, that proposal-function-pipe-flow failed to reach Stage 1? I want to be the first to broadly announce it myself in the announcement thread, after I’ve determined what the repository’s fate is going to be. [21:14:26.0418] > <@jschoi:matrix.org> sffc: Would you mind also getting rid of the mention, from your issue text, that proposal-function-pipe-flow failed to reach Stage 1? I want to be the first to broadly announce it myself in the announcement thread, after I’ve determined what the repository’s fate is going to be. Done [21:15:10.0865] Thank you! And welcome to the pipe room!🚰 [21:59:06.0040] https://static.wikia.nocookie.net/mario/images/4/44/SMB_Warpzone.png/revision/latest?cb=20200331123731