00:27:45  * basicdaysquit (Quit: I'm out)
00:29:03  * basicdaysjoined
00:45:28  * caridyquit (Remote host closed the connection)
00:46:01  * caridyjoined
01:00:29  * keith_millerjoined
01:03:48  * caridyquit (Remote host closed the connection)
01:05:27  * keith_millerquit (Remote host closed the connection)
01:06:04  * keith_millerjoined
01:06:49  * shachafquit (Ping timeout: 256 seconds)
01:12:43  * shachafjoined
02:04:19  * RobinMorissetjoined
02:08:46  * RobinMorissetquit (Ping timeout: 264 seconds)
02:09:31  * AtumTquit (Remote host closed the connection)
02:23:55  * not-an-aardvarkjoined
03:37:03  * vikash-afkquit (Remote host closed the connection)
03:51:39  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:04:33  * caridyjoined
04:07:11  <jmdyck>jschoi: Finally : `finally` Block is a chain production, so the the rule in https://tc39.github.io/ecma262/#sec-algorithm-conventions-syntax-directed-operations about chain productions applies
04:09:21  * caridyquit (Ping timeout: 265 seconds)
04:34:50  * keith_millerjoined
04:41:24  * jmdyckquit (Remote host closed the connection)
05:43:45  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:43:47  * gibson042quit (Quit: Leaving.)
06:25:21  * vikash-afkjoined
06:33:51  * jwaldenquit (Ping timeout: 240 seconds)
06:35:47  * jwaldenjoined
06:36:30  <jschoi>jmdyck: Ah, right, thank you.
07:05:51  * keith_millerjoined
07:08:47  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
08:06:21  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:23:23  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:11  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
10:55:52  * koddssonquit (Quit: Connection closed for inactivity)
11:24:21  * AtumTjoined
12:50:17  * howdoijoined
13:29:46  * jmdyckjoined
13:51:05  * jmdyckquit (Ping timeout: 276 seconds)
13:51:18  * jmdyckjoined
13:58:27  * jmdyckquit (Ping timeout: 240 seconds)
13:59:50  * jmdyckjoined
15:42:37  <littledan>I talked to some more delegates offline. I think there are TC39 delegates who prefer each of the proposals individually, and then there is also renewed interest in going back to :: and passing through `this`
15:43:25  <littledan>there was also support from some committee members about continuing on this path to develop things in parallel and collect feedback
15:45:09  <littledan>at this point, i don't think we necessarily need another presentation at the next meeting, just continuing on the current path to make the current options more complete and usable implementations deployed seems like it'll move things forward (although it will all take time)
15:47:06  <littledan>jschoi: there was definitely hesitation on the complexity of the smart pipeline proposal. I think this could partly be addressed by a simpler-looking document layout (e.g., maybe split off the explainer pieces about follow-on proposals into separate md documents?) and partly by thinking more about if anything additional should be made more minimal (e.g., considering a more restricted syntax for topic form, *or* just
15:47:07  <littledan>differentiating between the two by whether it contains # and explaining why the hazard isn't so bad)
17:31:03  <jschoi>littledan: Thanks for the update, and thanks again for making the presentation. Hearing of definite hesitation is discouraging but nevertheless expected, and I can do my best to address each respective concern.
17:31:16  <jschoi>Regarding the explainer: I can try separating the additional features into their own explainer documents. This is probably long overdue, but I have been focusing on the specification for the past week. I’ll make an issue for this in the smart-pipelines repository.
17:31:33  <littledan>jschoi: Fundamentally, it's not possible to address each concern. They are in contradiction with each other.
17:31:38  <jschoi>The specification is currently a single document too, with an annex for each additional feature. Is this similarly too confusing or overwhelming for the reader? Should I consider separating the specification also? Perhaps I should.
17:31:52  <jschoi>Ah, is that right? Hm.
17:32:12  <jschoi>How so?
17:32:47  <littledan>I think the specification being in one document vs multiple documents is less important, as many fewer people read and understand the specification compared to the explainer. The specification is usually unintelligible to most audiences, and difficult to the rest of them, no matter how you cut it.
17:33:03  <jschoi>Noted; thank you.
17:33:31  <littledan>well, to start, there's a concern about using too many punctuation characters. However, there is also demand for this feature. They are just plain in tension with each other, something we'll have to make a subjective tradeoff on
17:34:13  <jschoi>Ah, another third concern. Yes, that one’s tradeoff may only be mitigated, not completely resolved.
17:34:32  <littledan>language features end up making tons of subjective tradeoffs. The easy (though specialized; not everyone is as good at it as you) part is coming up with something unambiguous and consistent; the hard part is making these tradeoffs in a way that's deeply informed by the developer community
17:34:55  <jschoi>https://github.com/js-choi/proposal-smart-pipelines/blob/master/readme.md#distinguishable-punctuators is a goal in which this tradeoff is discussed, so that proposal makes its stand there.
17:35:09  <jschoi>Yes. As you say, many questions may be deferred until the Babel plugin is implemented for hands-on experience.
17:35:19  <littledan>oh, another contradiction: explaining everything fully vs concisely emphasizing the important stuff
17:35:30  <jschoi>The real-world examples hopefully help concretize how it would look, but…yes.
17:35:53  <littledan>the readme is very long! this means you have spoken to many things, but a portion of the audience will just be unaware of your thought process. This is an inherent difficulty
17:35:57  <jschoi>That’s true too. Maybe I should make an explainer explainer, pfft. Or separate the examples…? I think the examples do help make it seem more compelling.
17:36:02  <jschoi>Yes. Hopefully the readme split will help.
17:36:46  <jschoi>At least on a communicative level, though not so much at a fundamental-tradeoff level.
17:37:03  <jschoi>At least I don’t have to split the specification.
17:37:06  <littledan>my advice would be to think hard about these things, but ultimately understand that you're making opinionated decisions here, and the effort is based on this parallel effort to get developer feedback on the multiple paths
17:37:46  <jschoi>Definitely. So perhaps I should shift effort, from finishing the additional features’ formal specifications, to the Babel plugin.
17:38:59  <littledan>I mean, both are important. I really appreciate that you've done a good job on the specification, since this is important to validate the Babel plugin against
17:39:03  <jschoi>I have found that doing the former has helped clarify many tweaks I had to do to the core specification, for forward compatibility with the additional features, but few people will read the formal specification anyway.
17:39:23  <jschoi>Thanks.
17:39:33  <littledan>there's just a ton of work to do as champion; I don't want to ask too much of you; it may make sense to bring in more collaborators if it's overwhelming
17:39:53  <littledan>not sure if I mentioned test262 tests being another nice-to-have, to validate the Babel implementation against, in a way which will scale to other implementations as well
17:40:29  <jschoi>Yes, there is so much work. I have a little free time before my medical residency starts on July 1, so I saw an opportunity to help out here, while carrying on with other research.
17:40:50  <jschoi>Test262 seemed to be needed further down the TC39 process, but if they would help now, then I could look at doing those too.
17:41:21  <littledan>it's never too soon in the TC39 process to do these things. However, test262 tests would live as a PR and not land until after Stage 3
17:41:21  <jschoi>I just need to triage my priorities.
17:42:07  <littledan>I think you have the priorities pretty well: explainer -> spec -> Babel -> test262 or other things
17:42:07  <jschoi>Noted.
17:42:22  <littledan>I mean, seems like you've already been doing that
17:42:37  <jschoi>Well, if not many people read the specification…
17:43:40  <jschoi>The core proposal’s specification is done; even n-ary pipelines’ specification is just about done. I am currently specifying niceties like the feature for `do`-expression-like block steps and the feature for pipeline `try`statements.
17:44:19  <littledan>not many people read it, but it's really important to align all the implementations, tests and tools. Ordinary programmers are probably better off with higher-level docs.
17:44:24  <jschoi>Much of the purpose of these efforts is for showing the versatility and extensibility of the concept, but perhaps those are currently low-yield. N-ary pipelines were the most important thing to make sure the core proposal was forward compatible against.
17:44:51  <littledan>Oh, well if you want my opinion, you don't need a formal specification to prove out those extensions
17:44:52  <jschoi>Yes. I probably should pause specification work (especially since the core proposal’s sections are done) and make the readme more readable.
17:44:59  <jschoi>Noted.
17:45:03  <littledan>SGTM
17:46:19  <jschoi>As for the Babel plugin, James DiGioia and I had made progress, just about finishing Babylon’s parsing, which is good.
17:46:26  <jschoi>But I found out that there is no current infrastructure for doing block expressions properly, which is unfortunate, since it would have made the transform implementation for smart pipelines so simple.
17:46:38  <jschoi>Their `do`-expression plugin transforms them into IIFEs right now, which obviously would not work for `await` (https://github.com/babel/babel/issues/3780).
17:47:21  <jschoi>I had been hoping to utilize the same infrastructure…but it seems like I basically would have to properly implement block expressions—with variable declarations hoisted up out of inner expressions—myself. Ah, well.
17:47:33  <jschoi>Hopefully the payoff will be nice.
17:47:41  <littledan>in ordering, I mean feel free to not follow this, but I'd focus first on producing things really well for the most minimal proposal, and then going from there to the bigger ones
17:48:16  <littledan>I doubt the committee will have an appetite to do the follow-on ones extremely soon. There was a lot of concern raised about complexity budget, in multiple agenda items.
17:48:48  <jschoi>Definitely. I can imagine the syntax fatigue was real, especially after the `class` discussions. I am anticipating reading the notes.
17:49:26  <littledan>fatigue is one factor, but I'm not sure that word covers all the feelings
17:49:30  <littledan>if you can produce async IIFEs, that strategy could be part of a solution
17:50:05  <jschoi>Perhaps that is a better idea than flattening statements. I’ll have to look into that…
17:50:29  <jschoi>Even for just the core proposal, Babel support for transforming block expressions would have helped a lot. The core proposal is trivially isomorphic with nested block expressions. But nobody has done the work yet, so, ah well, someone has to do it.
17:52:18  <jschoi>As for complexity overload, I suppose I will just have to see whether the tradeoff is worth it in this case, once the Babel plugin is ready.
17:52:52  <jschoi>Thanks again so much for the presentation and for the feedback.
17:54:54  <littledan>I'm worried about using the completion value
17:55:07  <littledan>(we're discussing this in an issue)
17:55:24  <littledan>well, thank you for the presentation and the work on the proposal!
17:58:07  <jschoi>Using the completion value where?
17:58:15  <jschoi>Oh, also, for James DiGioia: Did anyone discuss his proposal’s issue over whether `=>` should be tighter or looser than his proposal’s `|>`? That question was on one of his slides, and he is interested in any feedback regarding it.
17:58:21  <jschoi>I suppose we could just wait for the notes too.
17:58:34  <littledan>in do expressions, and it seemed like bare blocks were based on that too
17:58:55  <littledan>no one raised an objection to that, but I was a bit long-winded so we didn't get to all the discussion topics
17:59:14  <littledan>but no one added it to the queue either
18:00:16  <jschoi>Well, neither block pipelines nor do expressions are mentioned at all in the TC39 pipelines presentation. do expressions themselves seem to have been languishing for a long time for those reasons you mentioned, especially for non-abrupt completions.
18:03:04  <jschoi>(Removing do expressions as an explanation of smart pipelines from the smart-pipelines readme before the TC39 meeting probably was pretty important for preventing association with an albatross, so thanks again for filing that issue.)
18:40:13  <littledan>I wouldn't characterize it as an albatross. Dave Herman talked about moving them forward recently, but it is controversial on its own
18:40:51  <littledan>Sometimes proposals are coupled, and sometimes they aren't. For example, nullary coalescing and optional chaining should, IMO, use some kind of vaguely analogous syntax and semantics. OTOH I don't think pipeline and do expressions are coupled
18:41:48  <littledan>yeah, it's true that we did avoid that discussion in TC39
18:44:50  <jschoi>They’re indeed not coupled, but pipelines can be expressed as nested do expressions fairly simply.
18:45:26  <jschoi>Nested IIFEs also work except for `await` and `yield`, the two function-scoped expressions.
18:46:55  <jschoi>Or, rather, the two function-scoped expression operators.
19:23:29  * howdoiquit (Quit: Connection closed for inactivity)
20:51:02  * not-an-aardvarkjoined
23:50:21  <littledan>Pipelines don't add expressive power to JavaScript, so I'm not sure what you mean by "can be expressed"