November 15, 2021 Incubator Call Notes: Pipe bikeshedding

Attendees:

• Chiyi Pin Lim (LCP)
• J. S. Choi (JSC)
• Ron Buckton (RBN)
• Richard Gibson (RGN)
• Sarah GHP (SHO)
• Shu-yu Guo (SYG)
• Tab Atkins (TAB)

Topic token

[Note: Double-caret ^^ as a topic token was accidentally not discussed during this meeting.]

TAB: (Presents bikeshedding table) We got % and ^. I think ^ is JSC's preferred choice?

JSC: Actually I prefer %.

TAB: Oh, okay, got it. Then there's @@, but it's not a valid decorator. Heavier weight, but nice and easy to type. Same with ##. Both draw on the analogy that Hack used. Hack is a PHP-derivative, where all variables start with $. It made its topic variable $$. So the choices for us here are %, ^, @@, and ##. JSC prefers %, and RBN and I both prefer ##. Also draws on the # prefix for private variables. I also like the visual weight of it.

RBN: I'm going to withdraw my concern about @@ since BFS commented there are other ways to do compile-time decorators.

JSC: I see the analogy for # as a topic token and # for private fields. They seem pretty different, but I understand the subjective part of it, since they’re both lexically defined “variables”. But it might be more confusing for learners if we say it's like private variables, since they’re actually pretty different concepts.

JSC: The fact that ## is two characters long is a tradeoff too. It's nice to make it bigger to see where it is in an expression. But I feel like when you get into two characters, if you're using a topic multiple times in a step it might get a bit long compared to one character. For visual weight I prefer % to ^ because % is a weightier character. I want to say that if we do go with a two-character topic I prefer @@ over ## because I'm concerned about nested noisiness with nested tuples and records. Scannability of ## compared to the other options when juxtaposed with tuples is going to be compromised, is my take on it. I do like % most. I would be quite worried about ##’s visual noisiness.

SHO: I want to make a case for why ^ is still cool. It's more visually distinguishable than it seems because of its baseline characteristics. I want to make a case for its scannability. ## and @@ are equally heavy to me which is too heavy for me, but it sounds like a pro to everyone else.

TAB: For %% I'll note that if we ever get a real modulo operator in JS it'll probably be %%. In which case it'll clash with our use of % here. We're accepting the fact right now that %%5 means "topic remainder 5", which will conflict if we have modulo.

JSC: If we go with JHD's suggestion to require space next to % [as if it were an identifier], it shouldn't actually close off the possibility of a %% operator. It would be visually confusing, yeah, if the %% operator becomes that common anyway. I suspect this operator would never get added to the language. But it shouldn't close off the % token grammatically anyway. It'd just be visually noisy.

TAB: Now that RBN has withdrawn his objection to @@, I know that's the symbol that's least likely to show up in a pipeline due to any other purpose. Putting decorators in a pipeline seems an extremely rare thing to do, compared to interweaving with records and tuples. Other symbols blend in a bit with the expression space. It has that as a pro.

JSC: I'm neutral towards @@. I think having two characters in a topic is more than necessary but also not the end of the world. I agree with SHO that one character would be the sweet spot. But if everybody else is really against % or ^, I'm fine with @@ as a compromise.

TAB: Yeah we can figure out the grammar for a single character but it'll be something we'll have to engineer around in the future. It'll require less maintenance going forward.

JSC: So you're worried about future extensions? Right now the problem with the grammar isn't that big; it's the same problem as / for division.

TAB: Yeah. I've been present during the Committee where people complained about /.

SYG: +1. The / lexing problem is an issue for implementations since it builds a tight coupling between scanner and parser.

JSC: I'm fine with weighing that heavily if it is a real difficulty.

TAB: I'm fine with @@. RBN has withdrawn his objection to @@. Anyone else have a problem with @@?

LCP: I agree with others that two characters is heavy. Is there a problem with single @?

JSC: Unfortunately single @ conflicts with decorators’ @(…).

LCP: Are we saying we'll agree to decorators within pipelines?

TAB: The pipeline allows arbitrary expressions. The less weird we can make this the better. If we have to remember odd restrictions only for parsing reasons, that's a lot less good than I would like it. I want to make it so we can refactor code.

JSC: I want to agree we want to reduce contextuality as much as possible. Although it would be weird we shouldn't forbid decorators inside of pipes.

LCP: I understand, okay. I feel like if we have two letters we're in a losing argument versus functional style where that ends up being fewer letters. Here we are worrying about misinterpreting that one special variable that references the current topic, whereas in the functional style the topic is explicit and you can name it. Here there are so many rules that need to support it, it seems like a lot of work and potentially leads to ambiguities. It may not help new programmers.

TAB: Can you explain what special rules need to be known for these? Like if you have an @@, what are the rules?

LCP: I agree there are no special rules for @@. But now we have more characters and we lost the first argument against the functional style where we had fewer characters. Now we have more characters than the functional style.

TAB: We never said that there were fewer characters…I suppose, versus a naked unparenthesized arrow function, it's the same number of characters. The point is that the character count is more or less a wash anyway, and that was the conclusion for one of my essays. Having it be two characters doesn't change the calculus in a significant way.

LCP: I prefer not to type two characters but if this is what we have to go with…

JSC: Yeah it comes down to how big of a deal the /-style contextuality is. To me it doesn't seem like it should be a big deal. But at the same time I respect when SYG says it's super annoying. From a human-reader perspective it's not hard. From a technical perspective, if that's a humongous deal, if someone will block on it, then that we have to go with a double.

SYG: [explains sweet.js’s problem with /, says that it complicates parsing for many systems]

TAB: I'd prefer we have one wart we deal with instead of N warts we all have to deal with similarly.

TAB: I'll call again, any objections against @@?

JSC: Not my first choice, but I’m fine with it. Better @@ than ##.

TAB: Anyone else?

[Silence from the group. Note: ^^ was accidentally not discussed during this meeting.]

TAB: Should we want to put this in plenary to socialize it a bit, or should we just go for it?

JSC: I'm not sure what the best course of action is. I can leave a comment on the issue at least. I'm fine with changing the spec and explainers too.

TAB: RBN and SYG, do you think this would be good to socialize?

RBN: At the end of the day, in my experience it's up to the champion group to change things like tokens. Not sure if it matters either way, but, like the Hack vs F# debate, it'll be more what the champions want and willing to make a decision one way or another.

SYG: Given the amount of grumbling in the side channels about pipelines when you all advanced to Stage 2, one thing to consider if you bring an update is there might be a tangential discussion on "should we continue with pipelines" that sucks up all the air.

TAB: Sounds like we shouldn't do that until we're ready to advance then.

Optional pipes

TAB: Next up is optional pipelines. One of the main reasons for pipelines to exist in the first place is to replace method chaining syntax. In method-calling syntax you have an optional call if you might have a null in the middle. Maybe you should be able to use optional pipes, too, in the same way. Syntactically this is reasonable: you prefix with a ?. My instinct here is that this should not be grammatically ambiguous. And I think the use case is reasonable. I don't use optional method chaining yet – I haven't had a reason to – but it was important to enough people in the language to have it in the language. So I think we should respect that and not have inconsistencies when introducing new calling styles in the language. Any objections?

JSC: I'm fine with whatever is more likely to succeed. The big question is whether to bundle it here or have a standalone proposal. I think optional pipe is reasonable, but it's about just whatever is most likely to succeed. Also there is the bikeshedding question of what to spell it too.

TAB: Given existing spelling rules I think it's a choice between ?|> and .?|> - the latter just for visual consistency where we’ve used .? in other places.

JSC: Are we talking about using actual optional chaining to do this? Because the precedence of pipe operator is way looser than member access. Right now it has the same precedence as assignment, the arrow function =>, and yield. It's quite loose, so it doesn't require us to parenthesize steps inside the pipelines. If we're integrating optional chaining, that'd suggest to me to change the operator precedence to make it tighter.

TAB: I'm not proposing we integrate with the optional chaining system. I was saying maybe since we already have dot . for visual consistency in existing optional chaining, we should apply the same here.

RBN: .? was not for visual consistency: it was necessary for parsing disambiguation, since you can have () or [] after a trinary-? today.

JSC: When I was talking about bikeshedding I was wondering if it was ?|> or |?>. I don’t have an opinion.

TAB: I don't care either way.

JSC: So should we try to bundle? My hunch is the Committee will balk if we bundle.

TAB: I have that intuition too, but I don't like splitting up proposals so atomically. I'll probably present it as an optional thing next time we present it. If there's positive feedback we can do it, but this is not something to sink it over.

JSC: Would that be when presented for Stage 3?

TAB: I guess. What's keeping us from Stage 3 at the moment? Reviewers?

JSC: The biggest thing is getting assurances that people aren't going to block.

TAB: In that case then for the topic of optional chaining, am I right the temperature here is that it's better to pursue it separately than to put the current proposal in any jeopardy. Any disagreement in the room? [silence] Taking silence as assent.

Reviewers and holism with other proposals

TAB: Next topic. We'll need to find reviewers. We should review the minutes and the chat logs to see who was trying to pull the post-agreement disagreement and get assurances of non-blockage ahead of time.

JSC: That's part of why I wanted to ask YSV [Yulia Startsev, Mozilla] to come, but she said she wouldn't have much to add. But her objections had weakened enough that she wouldn't block Stage 2. But we have no assurances from SpiderMonkey about Stage 3. And from SYG and V8 as well. There's that sort of thing happening. The fact that YSV didn't feel like she had much to contribute maybe means she's not going to block Stage 3?

SYG: YSV’s concerns here from what I recall was that this would radically change how JavaScript programmers write JS, and would have long-lasting effects on the ecosystem we don't yet understand.

SYG: Personally, I'm not sold on the “make FP [functional programming] better” vision, but Hack-style proposals have shifted the narrative away from the FP one.

RGN: This was also brought up in the last research call [on 2021-11-11]. There seems to be a large number of syntax proposals overlapping to such an extent that they should be considered at the same level. Pipe operator, partial function application, bind-this, and extensions. Because those proposals exist, it seems like pipelines advanced prematurely.

SHO: As a practitioner, I'm involved in the pipe proposal because this affects the kind of JavaScript I write everyday. As a practitioner, I don't think this is a divergence from how practitioners are writing JS today unlike other proposals like PFA.

RGN: I can agree with that, but my concern is that I don't think there's enough budget for all these proposals to make it in.

SYG: Arguing for the other side now, I don't think the kind of cohesion that folks want is sustainably achievable in JavaScript. Committee delegates often don't share goals, and we need to evolve the language piecemeal for the use cases of the users we care about. If we want to keep up with more adoption and more userbase, there's just going to be disparate needs that we have to consider.

SYG: I'll offer an anecdote as a C++ programmer, which many might consider to have crossed the line to be some incohesive kitchen-sink language some time ago. But, since then, progress has been made, and the language isn't so bad?

JSC: I'm looking at the research-call notes here. [“Observation that pipelines/bind-this/partial function application/extensions have lots of overlap but the space as a whole lacks sufficient problem/goal articulation…RGN: ‘Adoption of all, or even of two, leads to an incomprehensible language.’”] What's the overlap between bind-this and pipe, such that adoption of both or a combination leads to some incomprehensibility? Do you think pipe would block bind-this or vice versa?

RGN: I think that, of the four alternate call-syntax proposals, interaction between pipe and bind-this is not the most concerning of them. In this case the transitive interactions are more strong than the direct. Even so, looking at the examples in the bind-this explainer it says there would be benefit to the consideration of them together than considering them separately.

TAB: It is definitely the case that bind-this can be used as a pipeline operator. The problems of doing so are documented, but it doesn't mean that possibility is not there. I do see some of the overlap there can potentially be a concern.

RGN: Where the thing that moves through the flow of evaluations is the receiver?

JSC: What I did for bind-this was a corpus analysis. It found that most people do not use .call for pipelining but rather for prototype-pollution protection, using context objects as receivers, conditionally switching between two methods, and other purposes.

SHO: Pipelines seem to imply much less how to write functions than what a bind operator does. Does that seem accurate?

TAB: Absolutely, that's my objection to using bind as a pipeline operator. Because bind dictates you write your function in a weird way. Pipeline gives you complete freedom.

JSC: Yeah, bind as a pipeline would be quite prescriptive on developers. My current argument for bind-this is, excluding pipeline, .bind and .call are still very common and we should consider it on those merits. With regards to extensions, the extensions proposal is so broad I'm not sure where JHX [John Hax, champion of extensions] is willing to compromise. I know he’s willing to drop the special namespace, but I don’t yet know what else.

JSC: It sounds like what RGN is arguing for is that no proposal in this space advances to Stage 3 until all four proposals that could be used for data transformation are considered holistically.

RGN: That would have the best regret-minimizing outcome in the long term.

JSC: So it sounds like what you would say is you'd prefer that we not advance pipelines to Stage 3 until the other three proposals are re-presented?

TAB: I do think pipelines as it is currently written is best positioned to properly interact orthogonally with the other proposals. Even if we don't think it'll impinge on anything, knowing that other people do and working past that would be ideal.

JSC: I think there are three decisions we can take: (1) Which people should we try to reach out and how before proposing Stage 3? (2) Should we try to devote plenary space time to all four of these potentially data-piping proposals before we propose Stage 3 for pipeline? (3) I don't remember my third question.

TAB: It would behoove us to start up a thread at one of the repos, perhaps ours, discussing the holistic combination of everything, just to get a handle on it. So when we come into plenary we can point to something that we've discussed and we're at least aware of it so we have a better answer than "we don't know how this will work". At least give confidence that people have been heard, which is important.

JSC: As you know, there is already a thread about the interaction between this and PFA. But as you know this proposal’s repository is very hot. PFA syntax has always had an uphill battle, with or without Hack pipes. But do Hack pipes kill it? What about the other two proposals? These sorts of questions are tough – what's the end point? What more actionable stuff can we do there?

TAB: My idea is to not focus on any one proposal but to grab onto three or four things, so that we have a space to point to that we thought it through and considered the options. Doesn't have to be actionable, but to gather concerns and make people feel heard because they should be. Let's have a space to look at all the function-callee proposals at once.

JSC: Maybe also a wiki page on the pipes proposal to summarize the overlaps.

TAB: We'll grab YSV and the other folks who talked in the post-Stage 2 Matrix channel. And find reviewers.

JSC: I'll make a wiki page you can link to, TAB.