2021-03-02 [14:16:23.0000] bakkot: did you consider putting the emu-intro on the index page? [14:16:28.0000] instead of making intro.html [15:06:47.0000] considered it but decided I didn't care enough 2021-03-04 [19:24:11.0000] i feel like all the bugs i deal with are from await adding reentrancy where there wasn't any before [08:56:00.0000] how would you design a plugin system for a js engine where multiple plugins may want to override the same abstract op? [08:56:20.0000] like if you want to load two regexp proposals, but they both provide a replacement RegExpBuiltinExec [08:57:59.0000] i don’t think those can be compatible [08:58:11.0000] like you’d need to write a combo plugin, and those two shouldn’t be usable together [08:59:06.0000] i'm trying to think outside the box [08:59:30.0000] maybe you could fork execution, run both ops in parallel, then replay everything that happened onto the original [08:59:31.0000] plugins could write themselves as a diff to the spec, and like git, non conflicting diffs could be merged [08:59:48.0000] however, like git, you could still get conceptual conflicts that don’t concretely conflict [08:59:55.0000] yeah [09:00:00.0000] your fork thing is the same risk [09:00:19.0000] yeah idk if i would actually implement that 2021-03-05 [17:01:35.0000] question for anyone: Do you have a personal term for an + pair in an SDO clause? [17:14:11.0000] Long ago, I called it a 'group'. For a few years, I've been calling it a 'definition' (of/for the SDO). [17:27:14.0000] which is okay, but collides with the idea that the 'definition' of an SDO is the set of all such pairs. [17:27:17.0000] jmdyck: i do not, but a 'definition' sgtm [17:28:08.0000] tx [10:05:14.0000] jmdyck I am inconsistent but usually say "case" I think [10:49:56.0000] yup, "case" is a good answer. [13:25:03.0000] Random thought. Has anyone mentioned an await accessor "dot notation". As in an alternative to using: (await F()).a [13:26:04.0000] Sirisian|Work: https://github.com/tc39/proposal-eventual-send perhaps [13:26:26.0000] Sirisian|Work: but not every operation is "accessing a member of the awaited value" [14:04:37.0000] That proposal might be sufficient for what I said if the local cases are special-cased. F()~.a On a side note that proposal is fascinating albeit niche. [14:10:49.0000] Was trying to think with my WCF or Websocket RPC stuff if I'm ever written code that required that pipelining. His example of openDirectory(), openFile(), read() seems bad though. Most RPC stuff would just be readFile('foo/bar.txt'). Needs a lot more real world examples. [14:13:03.0000] Sirisian|Work: right but most async stuff isn't necessarily RPC. [14:36:09.0000] I think I get it. As in eventual send has to be implemented on the promise and if it's not then it knows it's local. [14:40:37.0000] Sirisian|Work: no, what i mean is, RPC is a pattern, one many people like myself utterly avoid, and i do many async operations where i am not promptly accessing a property on the fulfillment value, but instead passing the entire value to another function, for example. 2021-03-06 [17:03:10.0000] Sirisian|Work: More specifically, the "wavy-dot" proposal https://github.com/tc39/proposal-wavy-dot [17:03:54.0000] ah yes thank you [17:03:57.0000] Or, more generally, either of the pipeline proposals - `asyncFn() |> await |> #.foo` [17:04:31.0000] Interesting. I didn't know about that possible syntax. [17:05:27.0000] Man I'm really mixing the pipelines together. It woudl be spelled either `asyncFn() |> await |> x=>x.foo` or `asyncFn() |> await # |> #.foo` [17:05:34.0000] TabAtkins: Well, that’s mixing—yeah, haha. [17:11:23.0000] TabAtkins: Incidentally, my work has become freer, so I plan to actively develop both those proposals more again in a simpler form, if littledan is still willing to try championing. From what I recall from an email that ystartsev sent last fall, the rest of Mozilla wasn’t very enthusiastic about either proposal, but then the State of JS survey surprisingly showed community enthusiasm about them. [17:13:16.0000] oh nice, that sounds wonderful. i don't have time to *drive* the proposal, but I'd love to put effort into authoring stuff for the proposal if you've got time to champion [17:13:38.0000] The smart-pipeline readme should be culled a lot; I also don’t know how the work on Babel has been going…My medical residency is pretty time intensive, so I’ve been out of the loop for a while. [17:13:58.0000] Oh, well, I’m not an employee of a TC39 member organization unfortunately; littledan has been championing. [17:14:28.0000] …Unless Indiana University is a member without my knowledge, haha. [17:19:13.0000] it could become one :D [17:19:25.0000] (or you can be invited) [17:25:41.0000] jschoi__, Indiana University is indeed a member organization [17:26:45.0000] I am a student there, but to become a delegate, apparently you would need to be employed (at least that is what Sam Tobin told me) [17:27:41.0000] …Huh, wow. I should look into that. Thanks, DerekNonGeneric. [17:27:47.0000] "medical residency" "Are you a CS PHD?" "I'm something of a doctor myself..." [17:28:48.0000] jschoi__ if you're not in touch with twitter.com/samth you should reach out [17:28:48.0000] Haha, yes. [17:29:18.0000] bakkot: Definitely, thanks; will do. [17:32:33.0000] I have a question about the note in `Object.prototype.toString ( )` https://tc39.es/ecma262/#sec-object.prototype.tostring [17:32:46.0000] DerekNonGeneric go for it [17:34:48.0000] if this is not a reliable type test mechanism, what am I supposed to be using? [17:37:45.0000] I wonder if the suggestion is to use `instanceof` instead [17:38:30.0000] that depends on who you ask [17:38:47.0000] my answer is, you should not be trying to do a reliable type test mechanism [17:39:34.0000] that said, there are ways of checking all the JS built-ins; for example, to check if something is a Map, you can check if `Map.prototype.has.call(thing)` throws [17:41:42.0000] there's a proposal to add more things like Array.isArray, to handle this more generally: https://es.discourse.group/t/strong-brand-checking-in-javascript/557 [17:41:56.0000] because some people think it's a thing you should be doing, though I personally do not [17:42:46.0000] that said, no matter your opinion there you almost certainly should not be using `instanceof`, since it breaks when doing cross-realm things (e.g. if you make a new array in an iframe, that array will not be `instanceof Array` in the outer page) [17:47:13.0000] hmm, I had no idea about `Map.prototype.has.call(thing)`, thanks for all this, reading now [18:24:53.0000] jschoi__: IU is indeed a TC39 member [18:26:28.0000] jschoi__: Dropping https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5 real quick because the writing bug bit me this afternoon. Been running this essay in my head for a while. [18:47:18.0000] TabAtkins: "when is called" -> "which is called" ? [18:49:34.0000] Yes [18:49:51.0000] TabAtkins: Hey, this is great! [20:39:02.0000] DerekNonGeneric: https://npmjs.com/~inspect-js, and look at all the `is-*` packages, if you want to know how you can reliably do the kind of test that pre-ES6, Object.prototype.toString.call provided. [20:39:39.0000] DerekNonGeneric: short of those approaches, you might as well do `instanceof` or duck-type. [21:21:09.0000] ljharb, some of these are incredibly complex 😆 [21:23:58.0000] thanks for sharing this though, I had not considered pre-ES6 (now wondering if I should) [21:44:51.0000] TabAtkins: Reading through the Gist properly, I’m struck by your remarks that adding `(#)` to `unaryF(#)` wouldn’t be a big tax, in the sense that it’s what you’d already write today. It’s a reminder that Hack pipes (like F# pipes) are forward compatible with smart pipes, and I wonder if it would be worth making a small proposal and spec devoted to Hack pipes, at least as an experiment… [21:45:21.0000] DerekNonGeneric: yep, es6 breaking object toString created a huge mess, one likely now downloaded a hundred million times a week in aggregate :-p [21:49:10.0000] jschoi__: F# pipes are not forward-compatible with Mix pipes - `val |> logger(fn)` is valid in F# and a syntax error in Mix. But Hack-style is, yes. [21:50:01.0000] And I would be happy to propose starting from Hack and planning to see if "upgrading" to Mix later is warranted. [21:52:06.0000] TabAtkins: Oh yeah, it’s been too long. *Unlike* F# pipes, Hack pipes are forward compatible with smart pipes. [21:53:56.0000] And yeah, that’s exciting. I’ll see what I write up when I have time and ping you later. [21:55:17.0000] TabAtkins: Do you mind if I used that Gist as a starting point for the explainer? [21:55:35.0000] Please [21:59:50.0000] 👍 [02:51:51.0000] on the topic of pipeline, here are my draft slides for the upcoming presentation https://docs.google.com/presentation/d/1for4EIeuVpYUxnmwIwUuAmHhZAYOOVwlcKXAnZxhh4Q/edit [02:51:55.0000] jschoi__: TabAtkins ^ [02:52:11.0000] I wanted to get a couple smaller reviews before posting it on the agenda (sorry for my lateness here!) [02:53:22.0000] (I feel like these slides should maybe incorporate what you two are saying above; let me know if you want edit access. However, my personal opinion remains that placeholders are too complicated for v1) [07:35:44.0000] Oh I have a question [07:37:23.0000] Does any platform (like Azure Functions or Amazon Functions) use Compartment (frozen primordials) to speed up the setup of JavaScript environment? [07:38:02.0000] I think that's a very interesting use case and I'm wondering if any cloud providers are already using it [07:52:51.0000] Cool [07:55:34.0000] Did you report to chrome? [08:10:48.0000] Hhmm maybe compartment doesn't really apply to the serverless case. Codes run in different compartments share the same thread so if some one goes into dead loop, all compartments on the same JS instance will die [08:12:40.0000] am i the only one who can’t see anyone but jack speaking after “oh i have a question”? [08:13:05.0000] me too [08:13:22.0000] jack in dm claims robpalme is speaking but i haven’t seen them say anything [08:13:32.0000] robpalme: are you on matrix or something? [08:13:45.0000] maybe robpalme is a g-g-ghost. [08:14:00.0000] Rob Palmer it seems like you didn't set your bridge well. People on IRC can't see what you said [08:14:02.0000] jinkies [08:15:12.0000] i hope the bridge isn’t this unreliable or a bunch of convos might be missed :-/ [08:17:44.0000] lol [08:24:12.0000] is there a separate log for matrix that contains the missing context, so we can satisfy our public requirement? [08:28:03.0000] If people in IRC doesn't seem the message, the message is actually never appears on IRC. I guess this is not violating the requirement cause matrix bridge is not officially supported now? [08:29:27.0000] i think that’s a grey area; we’d have to ask lawyers. But i suspect given that it was set up by tc39 and bridged (even if only partially) that any technical discussion on matrix must be public and logged, or we’re violating the requirement. [08:30:27.0000] (this channel wasn’t even really supposed to be bridged; i thought it was just the delegates channel being experimented with) [08:59:38.0000] Rob just said. Can IRC see it? [09:00:32.0000] nope [09:01:51.0000] you can verify by checking the log link in the topic. [09:01:53.0000] Oops, unfortunate [14:42:13.0000] I don't think there's any legal requirement that a bridge exists; we just have to make the logs public [14:48:18.0000] littledan: Thanks for the link to the pipe presentation. I can try to edit it within the week to add TabAtkins’s thoughts. [14:49:03.0000] When’s the March meeting, again? [14:50:47.0000] starting Tuesday [14:52:07.0000] OK, sent you edit access jschoi__ [14:53:09.0000] ljharb: The Matrix logs are in the topic for each room, e.g., https://view.matrix.org/room/!wbACpffbfxANskIFZq:matrix.org for tc39 general [14:53:44.0000] Public logs were a big requirement that the inclusion group looked into in investigating Matrix [14:54:04.0000] turns out, if you use the matrix.org homeserver, and set the room permissions right, then you get the logs for free [15:02:53.0000] I tried to capture TabAtkins 's take in https://docs.google.com/presentation/d/1for4EIeuVpYUxnmwIwUuAmHhZAYOOVwlcKXAnZxhh4Q/edit#slide=id.gc578cf3263_0_0 but edits/feedback are appreciated [15:16:38.0000] littledan: One thing that TabAtkins and I talked about yesterday was phasing out the smart-mix pipe proposal (at least for now) in favor of just proposing simple Hack pipes. This is because Hack pipes would be forward compatible with smart-mix pipes, but F# pipes are forward compatible with neither. [15:17:59.0000] So my current plan is to archive the smart-mix pipe proposal and to make a new Hack-pipe proposal. TabAtkins said he does not have time to champion that Hack-pipe proposal, but I might be able to champion it myself with samth once I start my employment with Indiana University. [15:19:03.0000] Having said that, I’ve always seen my role in this case as playing devil’s advocate; I’m fine with both Hack pipes and F# pipes, even if I see more expressive potential in Hack pipes. [15:20:26.0000] well, my personal preference is F# pipes, though I do like hack better than smart mix [15:20:34.0000] (just out of simplicity) [15:20:42.0000] hack seems pretty nice tbh [15:21:21.0000] I think we've sort of had enough devil's advocate-ing and we should move into the consensus-building phase. So, if we can build consensus around hack, then great. [15:22:03.0000] I’ll be making a new proposal explainer and specification for Hack pipes sometime in the next weeks. [15:22:09.0000] sgtm [15:22:37.0000] Should your presentation mention those plans in the Hack-pipes section? [15:23:04.0000] oh, sure [15:23:21.0000] I guess I've personally gotten more shy about talking about my future work over time, but if you feel like it, I'm happy to share that to the committee [15:24:09.0000] Yeah, that makes sense. [15:24:27.0000] I’ll see what I’m able to whip up with regard to Hack pipes before the meeting in a few days, then. 2021-03-07 [16:06:32.0000] littledan: why do module fragments only work in esm? [16:07:01.0000] well, the mechanics I have in mind is something like, when you parse an ES module, you insert all of the fragments straight into the module map [16:07:13.0000] so this depends on it being embedded in something that has a module specifier [16:07:36.0000] hmm ok [16:07:43.0000] well [16:07:49.0000] maybe other mechanics are possible [16:07:50.0000] probably something to discuss more [16:07:54.0000] +1 [16:08:04.0000] file issues with ideas if they come to you? [16:08:21.0000] will do [16:08:29.0000] mostly i just want to combine blocks and fragments [16:08:36.0000] into one unified idea [16:08:36.0000] yeah, everyone does [16:08:40.0000] I just can't think of how it works [16:08:41.0000] haha [16:08:48.0000] I think maybe they can be unified at a high level? [16:09:07.0000] like, they have analogous syntax, and analogous semantics, sorta [16:09:13.0000] you don't really need to think about it too much [16:09:29.0000] I've been thinking about these two concepts roughly since last August and I just can't figure out how they'd be unified [16:09:55.0000] well we'll either figure it out or we won't P [16:09:59.0000] :P* [16:11:20.0000] yep, more investigation is always good at this point [18:15:43.0000] littledan: thanks, the url is what i was looking for. I agree there’s no requirement for a bridge [18:16:30.0000] littledan: is there a url that shows Jack’s comments and Rob’s that he was replying to? [18:18:33.0000] https://matrix.to/#/!NoxLEPPfqhdxdwIMkn:matrix.org/$1615045348117280Ybbkn:matrix.org?via=matrix.org&via=igalia.com&via=t2bot.io [18:18:44.0000] https://matrix.to/#/!NoxLEPPfqhdxdwIMkn:matrix.org/$1615046084117727CSUTn:matrix.org?via=matrix.org&via=igalia.com&via=t2bot.io [18:18:54.0000] https://matrix.to/#/!NoxLEPPfqhdxdwIMkn:matrix.org/$1615046656118071YzQWh:matrix.org?via=matrix.org&via=igalia.com&via=t2bot.io [19:20:24.0000] jackworks: hm, all of those seem to require me to actually log in to matrix - it's asking me to pick a client. any that are just the logs? [19:31:35.0000] ljharb: https://view.matrix.org/room/%21wbACpffbfxANskIFZq:matrix.org/ [19:32:25.0000] devsnek: right but that log doesn't have any of jack's earlier comments, nor rpbnmissing [19:32:28.0000] *rob's missing ones [19:32:43.0000] devsnek: iow that log does not appear to be the log of whatever channel *this* channel is bridged to [19:33:14.0000] oh [19:35:48.0000] ljharb: https://view.matrix.org/room/!NoxLEPPfqhdxdwIMkn:matrix.org/ [19:35:53.0000] different room [19:36:22.0000] devsnek: that says "User @2985302:matrix.org not in room !NoxLEPPfqhdxdwIMkn:matrix.org, and room previews are disabled (M_FORBIDDEN)" [19:36:28.0000] hm [19:36:34.0000] probably smth to do with it being a bridged channel [19:36:56.0000] we don't own it though, it's run by matrix/freenode [19:40:54.0000] so the logs of bridged channels aren't public then [20:16:00.0000] well that's not sketchy at all... Would <3 to know what Rob said, though lol [20:37:25.0000] jackworks, your link #3 for me: https://user-images.githubusercontent.com/17770407/110229072-b6349d00-7ed4-11eb-97a6-47ab9c1d9ea5.png [01:06:37.0000] In https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5, what do you mean by "[with F# pipes] `val |> foo + 1` is still a syntactically valid RHS, it'll just fail at runtime because NaN isn't callable"? Do you mean that `foo + 1` is either a number or a string, neither of which is callable? [01:06:56.0000] Sorry, at TabAtkins. [02:32:50.0000] The attempts at bridging have been broken for a while. I think we should assume that the brokeness will continue. Both channels are logged, so I think we are OK in terms of keeping things public. [02:33:18.0000] I am really confused by people saying that something here isn't public [02:34:34.0000] People can refer to the IRC log if they want to see all comments here. That is not going away. [02:35:31.0000] > 4:40 AM <• ljharb> so the logs of bridged channels aren't public then [02:35:31.0000] I can't understand this comment [06:26:16.0000] littledan: I’m looking for a log link that has the full conversation for which some parts never made it to irc, that does not require an account to view. [06:27:01.0000] The Matrix log does not require an account to view [06:27:36.0000] I don't know if you might have to piece together the IRC and Matrix logs manually, but this doesn't have anything to do with whether all messages are public [06:28:01.0000] I would prefer to discourage use of a bridge, unless someone can put time into fixing it [06:30:21.0000] sure, that’s fine (and i agree, bridges have never worked well in my experience). But i still haven’t seen any matrix log that contains Rob’s comments from the conversation in question. [07:16:21.0000] jschoi__: I'm assuming in that line that foo is a function, so foo+1 is NaN [07:17:20.0000] Wouldn’t `foo+1` be a string? Like `function foo () { }1` [07:18:58.0000] Is it? I was guessing. [07:20:24.0000] Yeah; either way, `foo+1` isn’t callable. [07:22:17.0000] So, yeah, `val |> foo + 1` fails at runtime for F# pipes…But this is assuming that the F# pipe has looser precedence than `+`. Which I’m assuming it would, unless they want to use parentheses around every RHS arrow function. [08:32:38.0000] littledan: Could I have edit access to those slides? [08:33:48.0000] littledan: Also lol at the "Rambda" typo, I see where your thoughts were. ^_^ [08:35:41.0000] i always spell lamda without a B, are they both correct, or am i wrong? [08:40:28.0000] ljharb: I don't see a comment from Rob in a Matrix room which is missing from the logs. Maybe we had a misunderstanding above? [08:41:25.0000] ljharb "Unicode uses the spelling "lamda" in character names, instead of "lambda", due to "preferences expressed by the Greek National Body"." [08:41:32.0000] littledan: jack PMd me some of robs comments that he was replying to, both of them in matrix, but only Jack’s comments made the bridge. so rob said some things that were heard within matrix, technical things, so our requirement as i understand it is that those appear in a public log - and I’m hoping to find that. [08:41:44.0000] bakkot: ah ok, so with B is the Americanized spelling? [08:42:10.0000] tbh unicode is the only place I ever see it spelled that way, so I dunno [08:43:07.0000] It sounds like the issue is maybe Rob's comments reaching Jack but not my client or the logs? I don't understand how the bridge relates to anything [08:43:46.0000] littledan: ah true, i just assumed. if nobody saw Rob’s comments but jack, on matrix itself, then maybe the bridge is fine but matrix itself is broken [08:44:37.0000] Let's continue for details in DMd [08:44:39.0000] DMs [08:44:48.0000] To verify details [08:45:55.0000] sgtm [13:38:25.0000] OK, ljharb and I worked out the error: people should not use the room #freenode_#tc39:matrix.org . It is not logged and does not reliably propagate messages anywhere in particular 2021-03-08 [06:58:19.0000] should probably update the topic of that room if possible [08:00:18.0000] bakkot, I guess `Map.prototype.has.call(thing)` would only be reliable if using the the frozen intrinsics (and to jackwork's point about the frozen primordials: I was under the impression that using those actually resulted in a net loss in performance, but would have to actually benchmark) https://github.com/nodejs/node/blob/HEAD/lib/internal/freeze_intrinsics.js#L126 [08:01:14.0000] DerekNonGeneric yes, in general if you are not running first so you can to capture untouched versions of the builtins you are entirely subject to the constrains of earlier code [08:01:30.0000] that was true even in ES5, when the intrinsic Object.prototype.toString was reliable [08:01:37.0000] someone could always have swapped it out [08:02:37.0000] cosign, there's no defense against first-run code for deniable things [08:10:10.0000] compartments! [08:11:23.0000] And that compartment can be fake too! [08:12:05.0000] hmm [08:12:12.0000] clearly we need compartment syntax /s [08:12:46.0000] lol [08:24:48.0000] compartments would work great as long as they're created by first-run code :-p [08:32:06.0000] gotta set a reminder to ask mark about compartment syntax on april first [08:39:16.0000] Testing. [08:39:19.0000] TabAtkins, littledan: I’ve archived the old smart-pipes proposal and pushed a new Hack-pipes proposal to https://github.com/js-choi/proposal-hack-pipes/. [08:39:25.0000] A spec is at https://jschoi.org/21/es-hack-pipes/. [08:39:41.0000] We’ll also need to update tomorrow’s slides, the general pipe proposal’s readme, and some of the general pipe proposal’s old GitHub issues. [08:45:22.0000] I’ve also swapped `#` with `%` in the explainer and spec, because I figure that `%` is less overloaded a token, but I’m fine with switching it back if it’s a big thing. [10:19:03.0000] jschoi__: I think you should probably stick with `#` for now to maintain continuity. Sigil bikeshedding is unavoidable, but there's no need to introduce it at the same time as trying to clarify affordances. [10:56:28.0000] gibson042: Good point. Done. [13:44:53.0000] jschoi: Do you want to make a PR against the main pipeline proposal to refer to this one instead of "smart"? [13:45:50.0000] (tbh I think switching to ? at the same time as talking about placeholders would remove a lot of the hesitancy) [13:53:56.0000] littledan: Yes, I will make a PR. But first, are you fine with me altering your meeting slides to refer to the new Hack proposal instead of the old smart-mix proposal? [13:54:09.0000] Also, I can switch the placeholder to `?` in both the proposal and the slides today. [13:55:48.0000] yeah I like the idea of using ? as a placeholder; it will get rid of the "yuck" factor for some people [13:56:20.0000] My problem with `?` versus `%` or `#` is that it’s visually overloaded with binary `??` and trinary `? :`, but this opinion is weakly held. [13:56:59.0000] Avoiding the yuck factor is probably than bikeshedding right now. [13:57:07.0000] *probably better right now [13:57:34.0000] I’ll edit the slideshow later today. I’ll edit the proposal and make the PR request after that. [15:05:13.0000] littledan: The presentation slides have been edited. I took out the stuff about smart mix, added more reasoning from TabAtkins’s essay to the Hack slide, and changed the Hack placeholder tokens from `#` to `?`. (As an aside, your slide 29, “Dan’s hot take”, has text cut off at the bottom; don’t know if you intended to do that or if you were going to tweak it later.) [15:06:18.0000] Yeah I have zero opinion on what the placeholder should be; if `?` makes people happier, that's fine. [15:06:55.0000] i suspect any change in placeholder will cause people to overindex on the placeholder [15:07:14.0000] and that since both # and ? have problems, we'll have to paint that bikeshed at some point, but hopefully not until the actual semantics are locked down [15:08:30.0000] jschoi: do you mind giving me edit rights on the repo? got some minor fixes i want to make in the readme [15:09:39.0000] TabAtkins: Done. [15:09:53.0000] Or invite has been sent, at least. 2021-03-09 [16:11:25.0000] can error cause be stage 4 yet 😢 [16:13:06.0000] devsnek it'll get there faster if you get started implementing it in V8! [16:13:13.0000] and also firefox [16:13:14.0000] and JSC [16:13:38.0000] you can just implement it in all of them yourself if you want [16:22:05.0000] lol [16:22:12.0000] i already have four open CLs in v8 [00:47:17.0000] jschoi: I think we should probably mention the smart mix for continuity, and explain why we're not pushing it anymore [06:31:39.0000] littledan: I’ve added a slide about “what happened to smart-mix pipes?”. I’ve also created a pull request updating the explainer of tc39/proposal-pipeline-operator, and I’ve updated its wiki too. [06:32:20.0000] jschoi: great, were you going to note the lack of Babel support so far? [06:33:17.0000] Do you mean lack of Babel support for Hack pipes? Should I add a note about that to the slides or to the tc39/proposal-pipeline-operator’s readme? [06:37:27.0000] I’ve added a note about Hack pipes’ need for Babel support to the final “what’s next?” slide. [07:21:01.0000] (I guess both) [07:46:58.0000] littledan: Got it. I’ve made a second pull request to the main repository. [07:59:48.0000] …Huh, looks like there was already work done in Babel on Hack pipes: https://github.com/babel/babel/pull/11600. This work should be revisited. We should also talk about whether to remove smart-mix support from Babel for now. [08:01:12.0000] well, my personal point of view (as I said in the slides) is that we should just settle on F# [10:22:32.0000] https://ci.tc39.es/preview/tc39/ecma262/sha/50db13ed40f0f82cbce9776a7c0bc3e48e3b0dab/multipage/ is the only page to review multipage? [10:22:47.0000] howdoi: it hasn't been merged yet, so the preview's the only place [10:23:01.0000] ljharb: noice, thanks. [10:23:54.0000] woot woot [10:23:57.0000] looks great 2021-03-10 [19:06:11.0000] littledan, TabAtkins: I left a slide with a screenshot of the summary table from the proposal wiki, near the end of the pipe-operator presentation. It might help sum up the options for the audience. You can edit/cut it as you think is appropriate. [03:46:04.0000] jschoi: A recurring problem in this proposal is that people are overwhelmed by its complexity, which leads them to react negatively to it. Your summary table in https://docs.google.com/presentation/d/1for4EIeuVpYUxnmwIwUuAmHhZAYOOVwlcKXAnZxhh4Q/edit#slide=id.gc6b314891c_1_0 is quite clear and helpful to me, but I'm not sure whether to present it, as I imagine that some people will just feel overwhelmed... [04:36:13.0000] FWIW, I agree that the table is clear and helpful [06:41:06.0000] jschoi: littledan the third to last row in that table is missing parens around the object literal in the arrow function RHS (and potentially around the “original” as well since the position is ambiguous) [06:53:54.0000] ljharb: Good catch. I’ll fix. [10:39:03.0000] littledan: Sorry to bug you, but you could share the slides with my normal email address (jackalmage⊙gc) rather than my work? I can only access Slides on my work account from my laptop, not from my (personal) desktop computer. [10:39:46.0000] (I'm still *very* pissy about our security folks removing the ability to read email/cal/docs on personal devices *right at the start of the pandemic quarantine last year*.) [10:40:56.0000] jschoi: Are the parens around the Hack yield example required due to yield precedence if more pipe follows that bit? [10:45:04.0000] TabAtkins: Yes, that is a special early error to prevent footgunning due to `yield`’s very loose precedence if more pipe follows it. I am open to removing the rule. [10:45:25.0000] Ahhh, I see. I have no opinion on it, I was just noting the discrepancy. [11:00:51.0000] TabAtkins: Sure, gave you access [11:00:58.0000] danke [13:06:08.0000] littledan: In your "hot take" slide you use "point-free can be bad when overused" as the reason to avoid placeholder/partial-application, but those are literally *point-ful*, it's the exact opposite of the point you're making. [13:06:47.0000] well, I guess that was written thinking more about smart mix [13:06:56.0000] Smart mix is also pointful. [13:06:59.0000] I guess I mean something more like "too complicated" rather than overused [13:07:15.0000] It in fact does *not* support point-free at all beyond the most basic "single named unary function" case. [13:08:42.0000] well, the slide says pretty clearly that the reason is excess complexity [13:09:04.0000] I stand by the statement that it's possible to go overboard on these features, and that it can be harmful to the learning process [13:09:25.0000] No, it says the excess complexity *of point-free programming* (as shown by stack-based/vector/etc) langs is a problem. And Hack/Smart-mix/partial-application are all *explicitly* point-ful to *avoid* point-free-ness. [13:09:45.0000] F#/minimal style are the ones that allow/support point-free. You're making the point exactly backwards. [13:09:52.0000] where did I say overused? [13:10:06.0000] "Functional, stack-based and vector languages show that you can go overboard on point-free programming and it's harmful to people learning the language" [13:10:16.0000] yeah, I meant overboard in complexity [13:10:26.0000] I think we're talking past each other. [13:10:40.0000] In that statement you're making a point about point-free style causing complexity. [13:10:41.0000] Right? [13:10:43.0000] there's lots of different idioms you have to learn to avoid creating variable names in those languages [13:11:12.0000] my basic feeling is, we should just tell people to go back and name variables when they hit those cases [13:11:19.0000] maybe it'll be more clear when I'm presenting it? [13:11:24.0000] and then we can argue in the Q/A? [13:11:30.0000] ...yes, okay, I agree. So that point is *exactly backwards* to the way you're using it. [13:11:44.0000] Happy to argue in the QA, but don't want the slide to present something that's straight-up wrong. ^_^ [13:11:46.0000] I think F# is simple enough [13:11:52.0000] that's a very subjective judgement [13:12:06.0000] I'm not saying anything F# being complex. [13:12:31.0000] I I mean, I think it's simple enough to satisfy the particular concern I'm raising [13:12:37.0000] I'm saying that your statement about point-free causing complexity is *only* a strike against F#-style. It literally does not apply to the others, they *do* have named arguments. They're pointful. [13:12:49.0000] I understand your argument [13:13:19.0000] in a different sense, Hack has its own complexity, and achieves an increase in expressiveness [13:13:28.0000] I'm not trying to make a value judgement here. I'm just saying you're making a statement that is exactly backwards in a factual notion. [13:13:29.0000] I'm specifically saying, "we just don't need to be so expressive" [13:13:46.0000] If your statement was about complexity in general it wouldn't be wrong. [13:13:59.0000] I guess, at a high level, I still see Hack as "point-free" kinda since you're not giving a name to your point [13:14:04.0000] (I'd *think* it was wrong, but then it's a value judgement that we can meaningfully disagree on.) [13:14:09.0000] The point is named ? [13:14:13.0000] yeah [13:14:16.0000] Like... that's literally its name [13:14:23.0000] I mean, there's a reason why we're discussing these together and not proposing them as two orthogonal features [13:14:26.0000] foo(1, ?) has a point exactly like foo(1,x) does [13:14:51.0000] and exactly *no* like `curry(foo, 1)` does [13:15:44.0000] But like pointful/point-free does have a definition, and that slide is currently factually backwards per that definition. [13:15:57.0000] I mean, the goal is to avoid forcing people to explicitly find names for intermediate values. That's what I'm calling "point-free" even though it's techncially wrong [13:16:02.0000] Don't [13:16:07.0000] sorry, hit Enter too early [13:16:11.0000] yeah that should have a different name [13:16:29.0000] like anonymous something [13:16:30.0000] Don't use words with well-understood meanings for your own custom meanings, particularly when the normal meaning is relevant to the discussion. ^_^ [13:16:43.0000] wait, is the meaning of "point-free" "not named"? [13:16:51.0000] No. [13:17:01.0000] i've never really understood the term, and i've always lightly assumed "point" is `.` [13:17:15.0000] Hehehe [13:17:26.0000] "point" means "place" in this case [13:17:41.0000] (as in 2-place function) [13:18:01.0000] bit of a weird word but it goes back many decades [13:18:17.0000] Yeah so like `flip(Math.pow)` is a point-free way to spell `(e,b) => Math.pow(b,e)` [13:18:30.0000] Manipulating the arguments without explicitly naming them. [13:18:30.0000] yeah. [13:19:31.0000] TabAtkins: so like using `.bind` instead of an arrow as a callback? [13:21:19.0000] Yes, `foo.bind(null, arg1)` vs `arg2=>foo(arg1, arg2)` is point-free vs pointful, because the arg2 argument is never explicitly indicated. [13:22:03.0000] I've never looked at the pipeline proposal in depth. Curious, it's not possible to make JS clever enough to pull object names into the scope of a pipeline as an alternative to "?" (are these called sigils?). function foo() { return { a: 1, b: 2 } }; foo() |> bar(a, b); Just thinking outloud. [13:22:34.0000] Sirisian|Work: I'm not sure what your example is trying to show. [13:22:56.0000] Oh I see, nm. [13:23:35.0000] No, it's not possible. Not because it's impossible technically (it def is) but because it breaks the "bindings should never show up dynamically" invariant that JS and most languages stick to. [13:23:36.0000] TabAtkins: ok with that understanding of the term, the JS community very strongly leans towards "pointful" programming [13:23:39.0000] TabAtkins: yes? [13:23:57.0000] TabAtkins: modulo the capital-F FP community [13:24:00.0000] ljharb: Yes, point-free (from Ramda and some others) is a minority position. [13:24:04.0000] ok thanks [13:24:07.0000] (I enjoy it, but it's definitely minority.) [13:24:47.0000] i use like it, but given all the array methods pass arguments i rarely need, i don't use it very often [13:25:01.0000] Sirisian|Work: That is, the `a` and `b` bindings aren't present in any lexical scope of the pipe body, it's instead created dynamically from the result of evaluating foo(), which is a no-no. [13:25:19.0000] *i like it, i mean [13:25:53.0000] ljharb: Yeah exactly, directly passing functions *would* be most useful in .map(), weighting by call-site usage, but that's precisely where you can't safely do it :/ [13:28:53.0000] Sirisian|Work: You can call the `?`a “placeholder token” or “topic sigil” or “topic reference” or whatever. And the precise token character is not final and would be bikeshedded later, if the Committee shows interest in advancing Hack pipes. [13:28:55.0000] I also prefer access to point-free style, but would not die on that hill for pipelines. `x=>` and `(x)` aren't *that* expensive in terms of comprehension [13:29:54.0000] Makes sense. I figured introducing random undefined variables would be weird. I usually like named variables, but the sigil works. Very compact. [13:30:30.0000] Sirisian|Work: not just weird, it would be a massive refactoring hazard from existing code [13:33:10.0000] Different than destructuring? [13:33:29.0000] if it was implicit, yes [13:34:49.0000] Yeah, if you explicitly indicated what keys were being drawn out of the return value of a method (to be made visible to the next pipeline step) it would be fine. 2021-03-11 [10:02:00.0000] Is it just me, or was the “Lexical Environment” section (ID `sec-lexical-environments`) removed from Ecma-262 sometime in the past few years? There are still references to “lexical environments” in some notes, but the phrase no longer seems to be actually defined anywhere in the spec. [10:03:18.0000] jschoi: it links here: https://tc39.es/ecma262/#sec-lexical-environments in 2022 and https://262.ecma-international.org/11.0/#sec-lexical-environments in 2020 [10:03:40.0000] jschoi: so yes, the term was removed during ES2021 [10:03:49.0000] looking for the PR [10:04:16.0000] So it got absorbed into Environment Records… [10:04:16.0000] jschoi: https://github.com/tc39/ecma262/pull/1697 [10:05:16.0000] ljharb: Thanks. Would it be worth submitting a pull request to change the last few references to “lexical environment” in the spec to “environment record”? [10:07:36.0000] yeah i think that'd make sense. it'd be up to the editors tho [10:09:13.0000] Yeah. [11:01:41.0000] Note that the spec still has the concept of 'lexical environment', insofar as every Execution Context for ES code has a LexicalEnvironment (as well as a VariableEnvironment). My recollection is that I left those few occurrences of "lexical environment" when they didn't appear to be referring specifically to the (former) Lexical Environment data structure, but to a lexical environment in a general sense, or in the sense [11:01:42.0000] an Execution Context. [11:04:37.0000] that was what i looked at the existing terms for, but i couldn't tell where they fell on that spectrum [11:05:32.0000] E.g., "ECMAScript function objects encapsulate parameterized ECMAScript code closed over a lexical environment ..." is, I think, just an introduction to the idea of function objects, using terms that the reader might already be familiar with from outside the spec. [11:12:51.0000] And in the note in 14.11, it would be incorrect to change "lexical environment" to "environment record", because then it's saying "the environment record of the running execution context", which isn't well-defined. (An execution context doesn't have a singular environment record.) [11:26:27.0000] jmdyck: Is the “lexical environment” concept the same as the LexicalEnvironment state component of the running execution context, as defined in Table 25? [11:26:58.0000] That being one of two Environment Records associated with the execution context. [11:28:08.0000] Because “lexical environment” is not defined in the spec now, but LexicalEnvironment is defined. [11:34:32.0000] I think that's basically the sense that 14.11 note intends. I don't think 10.2 is being that specific. [11:49:43.0000] Makes sense; thanks. [11:56:37.0000] yw [12:04:17.0000] It's very niche, but it would be neat if there was a syntax for setting multiple properties to the same value. The grammar rules are very specific for property names. { [a, b]: 1 } or { ['a', 'b']: 1 } or { { a, b }: 1 } or { (a, b): 1 } [12:20:08.0000] Sirisian|Work I don't think that comes up enough to warrant new syntax [12:20:11.0000] syntax is expensive [12:23:43.0000] Indeed. It comes up 4 times in my whole codebase. :P 2021-03-12 [08:03:52.0000] littledan, TabAtkins: At the recent meeting, did anyone voice any interest in taking over championing the pipe proposals? [08:04:10.0000] many people did, yes [08:04:32.0000] I believe Tab will be coordinating the whole gaggle from here [08:05:09.0000] Nice. [08:06:02.0000] Really appreciate all the work you’ve done for it, littledan. [11:11:49.0000] Yes, same. 2021-03-13 [16:16:29.0000] why is top-level await so complicated dawg [17:15:32.0000] loading dependencies is always complicated and adding asynchrony to things tacks on an exponent to the level of difficulty of anything [18:09:21.0000] TabAtkins, Regarding your previous comment, is that behavior different than how "with" works? [18:09:43.0000] "That is, the `a` and `b` bindings aren't present in any lexical scope of the pipe body, it's instead created dynamically from the result of evaluating foo(), which is a no-no." [18:10:39.0000] Got side tracked when we were talking and I was thinking that with was allowed into the language and it does something similar? [18:13:04.0000] `with` is widely understood to have been a mistake, which is why it's disallowed in strict mode code, and if you use it your code will be immediately deoptimized in ~every engine [18:18:52.0000] Curious could it be fixed to work sanely with a prefix. I assume people tried to fix it ages ago. with(o) { .a = 10; } or something? [18:19:54.0000] I guess that would create two variants of a language feature. meh. [18:20:06.0000] Yes it's one of the reasons `with` is bad [19:47:48.0000] :O https://gc.gy/83312253.png [19:51:26.0000] that is a surprising result [19:51:41.0000] especially since apply shouldn't be involved in argument spreading [19:51:51.0000] lol they're downleveling to apply and they're doing it wrong [19:52:00.0000] only happens when there's spread [19:52:13.0000] spread and then at least one more argument [19:52:26.0000] but also the optional chain should short-circuit [19:52:44.0000] yup [19:52:59.0000] devsnek link the bug, if you've filed one? [19:53:29.0000] or, I guess we're hoping this other person will do it [19:53:33.0000] ( https://github.com/tc39/ecma262/issues/2343 ) [19:58:12.0000] optional chain not short circuiting could be my fault [19:58:23.0000] but the code could've been touched since then [19:58:41.0000] Bakkot: https://bugs.chromium.org/p/v8/issues/detail?id=11558 [19:58:52.0000] i'll post some more info lol [19:59:04.0000] lol, not a great bug report [19:59:10.0000] thanks for the link [20:00:56.0000] monorail really needs monospace support 2021-03-15 [13:58:22.0000] that's probably a callprinter bug [13:58:41.0000] callprinter is one of those things we know need to be improved, but is a relatively large undertaking, and ends up being deprioritized by everyone [13:59:08.0000] you mean the error message? the "not short circuiting" seems like something else [13:59:10.0000] oh wait, that's not an error message bug report? [13:59:12.0000] it's actually wrong? [13:59:28.0000] yes, it should be just `undefined`, not throw [13:59:41.0000] it's failing to short-circuit [13:59:44.0000] ah okay i'll take a look today then... 2021-03-16 [17:17:48.0000] https://chromium-review.googlesource.com/c/v8/v8/+/2762426 2021-03-17 [00:35:10.0000] just landed Error#cause in JSC: https://github.com/WebKit/WebKit/commit/b03c4f4dada2c477376b9275332e08a3d08eba5f [00:35:29.0000] but does anybody know whether it will be added to the wasm error constructors? [00:35:37.0000] because it surely ought to be [04:41:43.0000] rkirsling: I guess that would require a PR to the Wasm JS API spec. Should it be supported for the DOMException constructor too? [10:24:56.0000] littledan: hmm good question [10:33:20.0000] it seems like it'd be useful on every kind of error subclass, really [10:33:40.0000] littledan: so it's possible that this is a JSC implementation detail because I haven't looked at said spec yet, but the wasm errors share the internal functionality of Error, while DOMException doesn't inherit from anything [12:50:18.0000] Would it be weird to allow: foo(true ? ...[0, 1] : 0) aka foo(...(true ? [0, 1] : [0])). Just thinking outloud since I saw it in some my code. [12:50:47.0000] yes, that would be weird [12:51:02.0000] the second thing is clear and follows from the existing rules without adding a new special case [13:52:00.0000] oh whoa [13:52:22.0000] seems like wasm errors outright defer to _NativeError_? [13:52:24.0000] https://www.w3.org/TR/wasm-js-api-1/#error-objects [13:57:12.0000] oh look littledan is the editor and everything 😊 [15:38:05.0000] Well, now ms2ger is the editor of that spec [15:38:34.0000] Oh yeah you're right, this should maybe "just work" for Wasm... [15:39:08.0000] But anyway from a normal developer perspective, you would probably expect DOMException to support this too [15:55:13.0000] yeah we designed it so that would work [15:55:21.0000] needs a PR to html I guess 2021-03-18 [22:43:48.0000] WebIDL presumably [00:16:59.0000] I found that the realms-shim repo has no activity since Oct 2020. What happened? 2021-03-19 [17:29:29.0000] Bakkot, Random thought. There's no mechanism to reference the current "returned" expression in the do expression, right? const a = do { 1; 2; console.log(output 2); 3; 4; } I'm not asking for it. Has this come up? [17:29:48.0000] Correct, and no, it hasn't come up [20:55:38.0000] Sirisian|Work: there is no "current" until the last thing happens tho - and console.logging it would cause the "returned" value to be `undefined` [09:42:28.0000] Oh right. Didn't consider that. [09:43:35.0000] Sirisian|Work: you could nest do expressions for what you want, i think [09:44:00.0000] Was thinking of stuff like for (let i = 0; i < 5; ++i) i; examples btw. Mind was wandering thinking of "what else does this allow". 2021-03-20 [18:40:27.0000] jmdyck: ping [18:40:32.0000] pong [18:40:49.0000] re: 545, I was thinking (and briefly discussed with the other editors) what the actual format should be [18:40:56.0000] I have a few goals here: [18:41:02.0000] 1) structured [18:41:05.0000] 2) minimal repetition [18:41:12.0000] 3) nice for human editors of the specification [18:42:04.0000] with that in mind, I'm inclined to suggest that the name and kind of the AO, and the parameter list and their optionality, be structured in the way they currently are: namely, by an `

` which is written in a particular format [18:42:25.0000] so the DL would just contain the description, the parameter types, and the return type [18:44:23.0000] along the lines of `

ExampleAO ( _foo_ [ , _bar_ ] )

parameters
foo: a Number
bar: an Object
returns
[etc]
...` [18:44:24.0000] thoughts? [18:44:45.0000] and ecmarkup would rewrite that to the thing which is currently output [18:45:18.0000]

format doesn't currently convey `kind` (completely) [18:45:32.0000] What's not covered? [18:46:00.0000] e.g., you can't distiguish a 'regular' ao from an record-method [18:46:22.0000] Isn't the `[[` sufficient to distinguish? [18:46:44.0000] record-method like "CreateMutableBinding ( _N_, _D_ )" [18:47:03.0000] ahh [18:47:06.0000] could just give those a different type [18:47:17.0000] ` ah, hm. [18:49:52.0000] different point: having param names in

and also
goes against "minimal repetition". [18:50:19.0000] yeah, shu was talking about maybe trying to invent some syntax to put the types in the h1, but we decided that was overkill [18:50:49.0000] I think the benefit in readability is worth the cost in repetition [18:51:13.0000] source-readability, you mean. [18:51:16.0000] right [18:54:11.0000] I agree that trying to put the 'types' in the h1 probably wouldn't work well, as in general it isn't a 'type', it's basically an assertion, and can be long/awkward enough that it wouldn't fit well in the

. (Even if ecmarkup stripped it out of the

on rendering, it would still be awkward in source) [18:56:07.0000] yeah. for the ones which are just like "a Number" it's fine but even "an ECMAScript language value" is pretty unwieldy [18:56:28.0000] yup. [18:57:03.0000] although i'm thinking we should introduce a shorter term for the latter. [18:57:30.0000] yeah, possibly, but probably separately from this PR [18:57:55.0000] in any case there's other ugly types, like "a List of names of ECMAScript Language Types" [18:58:37.0000] or "an Object that has [[Foo]] and [[Bar]] internal slots" [18:59:30.0000] or "either ~foo~, ~bar~, or ~baz~" [18:59:38.0000] yeah [18:59:58.0000] anyway if this seems reasonable I'll put together and publish a branch of ecmarkup which consumes headers in this format and we can see how it works in the PR [19:00:36.0000] could you get the auto-render to use that branch? [19:00:41.0000] yup [19:01:10.0000] will need to push a commit to the branch which specifies the new version, is all [19:01:36.0000] (or I could just tell you the version and you could do that yourself if you'd prefer) [19:02:55.0000] oh, btw, don't worry about trying to split it into multiple commits, I think; since the plan is to generate HTML which matches what's currently there, modulo some minor differences, my intention is to review the diff of the ecmarkup output rather than the input [19:02:59.0000] oh, you mean push a commit to the 545 branch [19:03:02.0000] right [19:03:58.0000] re reviewing the diff of rendered: yeah, that had occurred to me. was going to suggest it if at some point. [19:05:49.0000] one snag i can think of: there are a few ops that don't have their own emu-clause or

. [19:06:38.0000] seems like maybe something we ought to change anyway [19:08:04.0000] one set is thisBooleanValue, thisSymbolValue, etc [19:09:57.0000] those deserve their own clauses, definitely [19:11:03.0000] But if you just make a sub-clause in the obvious place, you're saying that it's a property of the Foo Prototype Object, which it isn't. [19:12:20.0000] natural place for those seems like the top level of their type's clause [19:12:36.0000] e.g. adjacent to Properties of the Boolean Constructor [19:12:51.0000] (probably as the last subclause under Boolean Objects) [19:15:06.0000] you mean new 20.3.5? [19:15:41.0000] yup [19:16:47.0000] or I guess 20.3.1, by analogy to 25.2.1 [19:18:19.0000] new 20.3.1 "Abstract Operations for Boolean Objects"? [19:20:34.0000] given that there's only one such AO I'm inclined to leave it at the top level [19:20:50.0000] personally, I think I'd prefer at the end 20.3.5 [19:21:32.0000] I'm fine either way; the actual placement of stuff doesn't end up mattering that much, given that generally people navigate by clicking through references rather than scrolling around [19:22:10.0000] yup [19:23:30.0000] re only one so leave it at "top level": but then if someone adds another, there's more diff [19:25:24.0000] unless they add it as another top-level. [19:26:17.0000] yeah but I'm not really anticipating any new AOs for booleans [19:26:22.0000] that said, I'm fine with that too [19:26:38.0000] though, if we do have a wrapper clause, it definitely belongs as .1 rather than .5 [19:27:44.0000] following 25.2.1, 25.3.1, etc [19:30:19.0000] Other cases: https://tc39.es/ecma262/#sec-makearggetter "An ArgGetter function is ..." [19:30:30.0000] ditto Setter [19:30:49.0000] that's not an AO at all, though [19:31:05.0000] The abstract operation TypedArraySortCompare [19:31:32.0000] (and will be refactored as of https://github.com/tc39/ecma262/pull/2109, or shortly thereafter) [19:31:59.0000] TypedArraySortCompare deserves its own clause; SortCompare already has its own [19:32:26.0000] and i have a PR to give it one, but I'm listing it anyhow [19:32:40.0000] There's the algorithm in https://tc39.es/ecma262/#sec-array.prototype-@@unscopables [19:32:43.0000] hah, so you do [19:33:27.0000] that algorithm is not an AO, so no problem there [19:33:45.0000] well, i wasn't limiting myself to AOs [19:34:48.0000] I'm looking at all cases where an *isn't* what the

advertises. [19:35:08.0000] let me rephrase: that algorithm is weird enough that I don't think we should be trying to stretch the header format to accomadate it [19:35:28.0000] (*accommodate) [19:36:40.0000] but that does raise the question of what you want
s for. [19:38:11.0000] well, I'd thought the goal was just abstract operations, at least to start [19:38:18.0000] that's what the title of the PR implies, at least [19:40:07.0000] though i see michael also asked for them for built-in functions, sigh [19:41:13.0000] on that question, it is much less obvious to me that there's value in having structured headers for built-in functions, since those all always take ES values [19:41:35.0000] (plus we haven't done the exercise of making them consistent yet) [19:41:48.0000] but I will raise it with the other editors, again... [19:42:14.0000] I do prefer keeping the scope relatively small, to start [19:42:30.0000] so that there's some hope of landing it before another five years pass [05:20:05.0000] test [06:43:58.0000] I can see you [10:27:51.0000] Bakkot: i just noticed we're allowing control flow in do expressions now :O [10:34:19.0000] tentatively, yes [10:34:58.0000] very exciting [10:35:05.0000] curious what made you change your mind [10:41:14.0000] waldemar said he'd block the proposal as being not worth the syntax cost, was the proximate cause [10:41:39.0000] and then I surveyed delegates and slight majority of those who responded were in favor of allowing [10:42:29.0000] ah [10:45:28.0000] going to try to run a brief user study to make sure it's not too confusing, also [10:50:56.0000] 👍🏻 [16:55:27.0000] Bakkot: re including parameter 'type' info in the heading: it occurs to me that it would be fairly readable-in-source if we put each parameter + 'type' on a separate line. (remembering that ecmarkup can still generate the

as it likes) [16:55:37.0000] strawman example: [16:55:45.0000]

[16:55:45.0000] CreateDataProperty( [16:55:45.0000] O : an Object [16:55:45.0000] P : a property key [16:55:45.0000] V : an ECMAScript language value [16:55:45.0000] ) [16:55:45.0000]

[16:56:50.0000] yesterday I was thinking of trying to stuff it all onto one line, which would be hard to read, but I think something like the above could work. [16:57:27.0000] hmm, yeah, interesting thought [16:58:41.0000] and then that would eliminate the repetition of param names between

and
. 2021-03-21 [17:01:12.0000] something else I was wondering about: typically, you'd have

followed by
followed by , but [17:02:15.0000] there are occasionally other things (e.g., an ) that crop up. Do you have a sense of whether you'd always want

+
together, or
+ together, or whatever? [17:02:52.0000] I think probably the h1 + dl together [17:03:19.0000] I was going to experiment with generating the "It performs the following steps when called" if and only if the dl is immediately followed by an emu-alg tag [17:03:32.0000] so that it also work for things defined by tables or whatever [17:03:40.0000] ah, ok [17:03:55.0000] [gotta go, will check back later] [18:51:25.0000] Bakkot: https://github.com/bakkot/do-expressions-v2/issues/9#issuecomment-791889482 can you check out this [18:51:32.0000] Thank s [19:37:35.0000] ljharb, Question. Is that static block proposal stage 3 now? [19:38:18.0000] I've been following that one for a bit. Caught my eye that it updated. [19:40:58.0000] Also random question. Has anyone discussed adding static variables to functions as a syntax? I think right now function f() { f.a = 5; } is like the convention. Did anyone ever bring up syntax sugar for that? function f() { static a = 5; } type thing? [22:53:41.0000] Sirisian: no, it's stage 2, see https://github.com/tc39/proposals [22:53:56.0000] Sirisian: and no, i don't think that would get very far since it's an incredibly bad pattern. [22:54:31.0000] Sirisian: static blocks are per-definition; something like what you describe would be once per-invocation, which isn't how "static" generally operates. [23:00:18.0000] pretty sure it's stage 3 [23:00:52.0000] The meeting notes had like a comment about changes needed, then they were made I think. I skimmed. [23:03:18.0000] "it's an incredibly bad pattern" oh c'mon. All the cool languages have it. C++... php... probably others. These are bad examples. [09:17:55.0000] hm [09:21:10.0000] Bakkot: ah right, it was conditionally stage 3 in january [09:23:35.0000] k, repo's updated. [09:23:41.0000] Sirisian|Work: my bad, it is indeed stage 3 [09:24:55.0000] Sirisian|Work: re the pattern, i'm familiar with it from php, and in that case it's a closed-over variable, because PHP lacked that functionality at one time. in JS, you can already do this. 2021-03-23 [17:26:50.0000] I assume Sirisian|Work was meaning `function f() {}; f.a = 5;`, so it's once-per-definition? Once-per-invocation is just a normal local variable, right? [18:05:21.0000] TabAtkins: if it was once-per-definition it'd be alright, but then it couldn't live inside the function body block [18:06:17.0000] I mean, it could with an appropriate indicator. [18:06:31.0000] Like the suggested `static a` [18:07:03.0000] yeah but it'd be weird to be inside the function block body and not be per-invocation imo [18:07:45.0000] Eh, it's just more hoisting 😃 [18:07:58.0000] more of one of the worst parts of the language, yay :-p [11:17:08.0000] TabAtkins, yes, sorry. [12:52:30.0000] is anyone working on tests for import assertions [14:21:33.0000] What’s the name of that tool that can create statistics about public NPM packages’ source code? I remember it being called something similar to “Sauron”…I want to use it to determine the prevalence of hex-code escaped characters and non-printable characters in strings. [14:34:17.0000] jschoi: gzemnid? [14:34:38.0000] https://github.com/nodejs/Gzemnid [14:34:46.0000] devsnek: Yeah, thanks, that was it. [14:35:04.0000] 👍 [14:36:09.0000] I'd hope no one is doing the latter. I use non-printable characters in my custom Word editor I wrote in JS, but only in the String.fromCharCode(8203) form. [14:36:47.0000] i use a zero-width space in a popular package [15:21:17.0000] ljharb: Any particular reason why you embed the ZWS directly in its source code? Asking out of research interests. [15:23:45.0000] jschoi: i wanted to make a property that was hard to find in an autocomplete, and that printed as an empty string, and that couldn't collide with the easy value of `''` [15:24:00.0000] it's for https://npmjs.com/prop-types-exact, a bit of a hack around how react works with propTypes [15:25:36.0000] Sorry, I mean: did you embed the ZWSP directly in the source code, or did you use an escape `'\u200B'`? [15:27:57.0000] Ah, looks like it was escaped. [15:28:17.0000] And then assigned to a variable and then interpolated in a template string. [15:38:19.0000] the scripts I ship have raw non-printable characters in strings under some circumstances [15:38:25.0000] they're output by a build tool [15:49:12.0000] jschoi: ah yes, i used the escape for "just in case" [16:58:53.0000] where is the code for the automated minutes thingy? 2021-03-24 [17:12:03.0000] devsnek https://github.com/bakkot/transcribe-to-gdocs [17:12:17.0000] thx! [17:12:28.0000] gonna make a version of that for discord voice calls [17:16:41.0000] this will work for that without modification [17:16:55.0000] it transcribes your computer's audio out directly [17:17:01.0000] doesn't hook into zoom or whatever [17:17:34.0000] (that said, the way I've been doing it requires a second computer, so that I can also hear and participate in the call myself) [17:17:55.0000] (or rather it transcribes audio _in_, and I have my computer route audio out to audio in) [17:19:22.0000] Bakkot: you get a separate audio stream for each person on discord [17:19:25.0000] so if i hook it up directly [17:19:32.0000] i can label them by username automatically [17:19:41.0000] oh, nice [17:20:01.0000] well technically this is all undocumented [17:20:10.0000] but hey if it works it works [17:26:02.0000] you'll probably have to muck around with the internals of https://github.com/gillesdemey/node-record-lpcm16 a bit [17:29:43.0000] (or replace it outright; it's just a very simple wrapper around `sox --default-device --type wav -`, so if you already have access to the audio streams you need, as streams, you don't need it at all) [18:28:03.0000] Bakkot: apparently you can pass words that are likely to be spoken to make it more accurate (might help reduce the string replacement) [18:28:09.0000] https://cloud.google.com/speech-to-text/docs/reference/rest/v1/RecognitionConfig#SpeechContext [18:28:25.0000] i tried it and didn't have much luck, so went back to my regexes [18:29:16.0000] f [18:29:31.0000] did you try diarization [18:34:10.0000] uhhhhh can't remember [18:34:27.0000] if I did I didn't get very far [18:34:32.0000] possibly it only works with certain models? [07:32:26.0000] Bakkot: i found you can get rid of the custom writable stream by using stream pipe/unpipe instead, since that automatically handles backpressure [08:55:26.0000] Hi. Had a feature idea and TC39 website led me here. [08:55:45.0000] The feature is to add well-known symbols Object.{keys,values,entries} to Object.prototype. [08:57:07.0000] The rationale is that I want to be able to keep chaining through arrays even with an object in the middle. [08:57:14.0000] An example would be: const x = (array.filter(x=>x).map(x=>f(x)).reduce(intoObjectSomehow)[Object.values]().map(y=>g(y))); [08:58:27.0000] Since it would be a well-known symbol on Object, it would avoid the for-in and in-keyword and similar things picking up on it, but would otherwise be a safe and encapsulated way of adding .toKeys(), .toValues(), and .toEntries() to every object. [09:01:09.0000] sdegutis: that's not a viable approach for a number of reasons. one is that many things inherit from Object.prototype for which these instance methods would be nonsensical, like `true[Symbol.values]()`. one is that it's not ergonomic to access symbol methods, which is why they're typically used for protocols and not accessed directly. another is that not all objects inherit from Object.prototype (`Object.create(null)`, or the `ns` in `import * [09:01:09.0000] as ns`) [09:02:04.0000] Ah good points. [09:02:10.0000] If your goal is chaining with functions that aren't prototype methods, you may be interested in the pipeline operator proposal https://github.com/tc39/proposal-pipeline-operator [09:02:11.0000] I suppose the |> thing solves it also, maybe. [09:02:19.0000] Yeah that. [09:02:20.0000] it does indeed [09:02:37.0000] Well I hope it gets here soon. Lodash and ramda do not play very well with TypeScript. [09:02:46.0000] Or maybe I'm just using it wrong. [09:02:53.0000] Anyway thanks ljharb for your feedback. [09:02:58.0000] np [09:11:41.0000] `const x = array.filter(x=>x).map(x=>f(x)).reduce(intoObjectSomehow) |> Object.values(#).map(y=>g(y))` hell yeah pipeline letting every call pattern integrate into method chains [09:14:45.0000] We should capture this as a real-world use-case in the slides. [09:14:50.0000] And by "we" I suppose I mean "me". [09:16:05.0000] TabAtkins: my biggest one is `Object.fromEntries(Object.entries(obj).filter(…).map(…))` etc [09:16:43.0000] TabAtkins: will be super nice to do `obj |> Object.entries(?) |> ?.filter(…).map(…) |> Object.fromEntries(?)` or similar [11:32:43.0000] ljharb: i think you broke the grouping of the legacy box around the __define/lookup__ methods [11:32:51.0000] they each have a separate one now [11:33:23.0000] whoops, it was a tricky rebase. Can you fix it? :-) if not, I’ll try to fix it later today 2021-03-26 [16:19:46.0000] Maybe I'm not thinking this through, but was it ever discussed on how to const b in code like: ({ a: o.a, b } = { a: 0, b: 1 }; ? [16:24:28.0000] });* 2021-03-27 [18:48:10.0000] I keep forgetting you can't write a?.b = 1; Surprised that was closed. I never read the meeting notes so I assume it has a huge downside. [18:58:04.0000] a.querySelector(':first-child')?.hidden = true; for reference, which has an obvious "?.setAttribute(" solution. So used to not using setAttribute. [20:35:27.0000] littledan: hi I missed your presentation of module fragment on the last meeting but I check the repo and I think it's useful [07:15:34.0000] jackworks: That's nice to hear! I was hoping we would have an incubator call about the topic, but I have not arranged it yet. 2021-03-28 [07:04:12.0000] https://github.com/Jack-Works/proposal-freeze-arraybuffer-and-readonly-view 2021-03-29 [17:54:56.0000] jmdyck: re: multiline

s: that works less well for optional parameters, I would think [17:55:04.0000] did you have something in mind for that case? [17:58:23.0000] rather than indicating optional params by putting brackets around them, you could just pick a way to indicate optional-ness of each param on its line. [17:58:51.0000] In my pr, I say e.g. "_foo_ : (optional) an integer" [17:59:40.0000] (ecmarkup would presumably complain if a non-optional param followed an optional) [18:26:08.0000] hmmmm [18:26:23.0000] that doesn't express all present in, e.g., `GetIterator ( _obj_ [ , _hint_ [ , _method_ ] ] )` [18:26:30.0000] *all the information present in [18:42:07.0000] are you thinking of the possibility of ( _a_, [ _b_, _c_ ] ) ? [18:42:35.0000] yes, as in `FlattenIntoArray ( _target_, _source_, _sourceLen_, _start_, _depth_ [ , _mapperFunction_, _thisArg_ ] )` [18:45:15.0000] Well, like I said ~5 years ago, "Or you could acknowledge that there will always be limits to the invocation constraints that can be expressed in the parameters, and just decide that coordinating the optionality of two parameters is beyond that limit. (I.e., just say it in the description and enforce it in the alg.)" [18:45:55.0000] (Note that FlattenIntoArray's alg does enforce it.) [18:48:19.0000] It looks like FlattenIntoArray is the only such case. [18:49:13.0000] mm, yeah, that's an option [18:50:22.0000] I should ask, for the purposes of balancing these tradeoffs, is there a thing you're looking to accomplish with structured headers? [18:56:22.0000] mainly to make it easier to do static analysis. [18:59:50.0000] I also think that having the structure will encourage spec-authors to fill it in, which will improve the spec for human readers. You could accomplish that without structured headers, but I think it would be harder. [19:00:50.0000] I imagine having everything 'declared' will also make things somewhat easier for implementers. [19:02:34.0000] And it provides a place to put future useful info, like https://github.com/tc39/ecma262/issues/2283 [19:03:07.0000] (which is maybe just an aspect of the 'static analysis' point) [19:08:55.0000] (oh, it also takes care of https://github.com/tc39/ecma262/issues/253) [19:11:59.0000] gotcha [19:12:03.0000] so, thinking it through some [19:13:12.0000] I think we should stick to just AOs to start, since built-in functions are not yet consistent, and making them so shouldn't be part of this PR [19:13:42.0000] which means that there will continue to be headers which use the `[` notation for optional arguments [19:14:20.0000] and I hesitate to have two different notations for optional arguments, even though they'd be used for different types of things [19:14:46.0000] which leads me towards putting the types in the dl, at least for now [19:15:23.0000] separately, I don't want to handle return types until after we fix https://github.com/tc39/ecma262/issues/1796, [19:15:38.0000] since there are lots of things which don't logically return completion records, and I don't really want to write down that they do [19:16:29.0000] you don't have to. it depends on how you define the semantics of the 'returns' section. [19:18:21.0000] it's hard to define the semantics of that section, because it's not in a consistent state right now [19:18:25.0000] So to fix 1796, you're planning to insert a "Returns foo." sentence into every preamble? [19:18:49.0000] Something like that, yes. [19:19:09.0000] Not sure exactly what the wording for the completion record case will be yet. [19:19:35.0000] "It returns a Completion Record which, if its [[Type]] is ~normal~, has a [[Value]] which is a Foo.", maybe [19:19:49.0000] or in the non-completion record case, "It returns a Foo" [19:20:44.0000] or, possibly, not a sentence, but a new clause in the first sentence, as in "The abstract operation ExampleOp takes arguments _foo_ and _bar_ and returns a Foo" [19:21:38.0000] re "It returns a Completion Record which, if its [[Type]] is ~normal~, ...": (1) ick, and (2) https://github.com/tc39/ecma262/issues/497 [19:22:04.0000] editors are strongly opposed to the approach in the OP of that issue [19:22:10.0000] (myself included) [19:22:28.0000] They've never said so. [19:22:58.0000] hmm, I'll try to get something from the group on record [19:23:06.0000] I'm opposed, at any rate [19:23:13.0000] for the reason Domenic gave in that thread [19:23:23.0000] Domenic didn't understand it. [19:24:22.0000] perhaps I don't either then? [19:24:25.0000] or he mistook the reasoning [19:25:04.0000] or maybe i'm thinking of something else. [19:26:31.0000] No, yeah, he said "It seems the motivation here is brevity (omitting !)", and I responded that was incorrect, and he never replied. [19:26:44.0000] ah, sure, I agree he misread the motivation [19:27:51.0000] let me state my own reasoning, then: I am uncomfortable with anything which allows you to touch the return value of an AO which can throw without explicitly unwrapping the value [19:28:17.0000] that is, having a return type along the lines of "string, or an abrupt completion" is bad, because a consumer can treat that as a string [19:28:54.0000] it is not correct for them to do so, but it's an easier mistake to make than in the case that the AO always returns a completion record [19:30:03.0000] it's already possible in the status quo to "touch the return value of an AO which can throw without explicitly unwrapping the value" [19:30:23.0000] yup, and that's one of the things #1796 would aim to fix [19:30:29.0000] (step 5, "Remove the bit which allows implicit unwrapping of completion records") [19:30:35.0000] how is 497 worse? [19:30:48.0000] oh, it wouldn't be worse than the status quo [19:30:59.0000] but it would be a two-steps-forward one-step-back kind of thing [19:32:19.0000] but 497 does eliminate implicit unwrapping [19:32:32.0000] yes, and that's a step forward [19:33:36.0000] so what's the step backward? [19:34:29.0000] it leads to a world where "1. Let _x_ be Foo(_bar_). 1. Return _x_ + 1." would be coherent, even if Foo could sometimes throw, as long as Foo would not throw for this particular line. [19:35:16.0000] But I explicitly say that you don't have to omit '!'. You can still require '!'. [19:36:15.0000] The thing which would require `!` in that case would be a line of prose which said "in order to refer to the return value of an AO which sometimes returns abruptly but cannot in the particular case in question, you must prefix the call with `!`", presumably? [19:36:26.0000] but I want the "type system" to ensure that [19:37:06.0000] yes and yes. [19:37:30.0000] if you want the "type system" to ensure that, it'll be better to have a good type system. [19:37:39.0000] well, yes, agreed [19:37:57.0000] but even with the very ad-hoc one we have, I think the same principle applies [19:38:58.0000] what i'm implying is, Normal Completions don't make for a good type system. [19:39:05.0000] how not? [19:39:31.0000] Either is a pretty typical building block for things like this, in my experience [19:39:48.0000] rust, e.g., formalizes it in Result [19:41:17.0000] ok, but Either isn't what the spec is doing. It's doing more like Either [19:41:35.0000] and that's a lot of cruft that just gets in the way. [19:42:20.0000] 497 is actually trying to get the spec closer to Either [19:42:32.0000] i think [19:43:03.0000] I definitely think of the Completion type as pretty precisely equivalent to Result [19:43:29.0000] hm [19:44:34.0000] Inventing a new language in the spec 🤔 [19:44:44.0000] but it has an explicit [[Type]], which Either<> doesn't involve [19:46:21.0000] that's pretty much an implementation detail; rather than introducing explicit ADTs, the [[Type]] serves the role of the enum case here [19:47:32.0000] that's the usual approach in, say, typescript: the way you write `Result` in TS is `{ type: 'error', value: E } | { type: 'ok', value: T }` [19:50:21.0000] so when you think of eliminating implicit unwrapping, you think of '!' as explicit unwrapping? [19:51:01.0000] yup [19:51:36.0000] that's the `set val to val.[[Value]].` bit of `!` [19:51:56.0000] (I would remove the `If val is a Completion Record,` part which precedes that bit, since it would always hold) [19:52:26.0000] yeah, i know it does that, the question is whether that's implicit or explicit. [19:52:44.0000] yeah, I would consider that explicit [19:52:49.0000] brief, but explicit [19:52:59.0000] I think 497 views it as implicit. [19:53:56.0000] hmm [19:53:57.0000] say more? [19:54:10.0000] to be clear: 497 is not trying to eliminate '!', rather trying to eliminate the unwrapping that happens in '!'. [19:54:30.0000] (among others) [19:55:01.0000] yeah [19:55:17.0000] my problem with `!` is the "If val is a Completion Record," part, not the "set val to val.[[Value]]" part [19:55:25.0000] it sounds like you have the opposite view? [19:55:57.0000] or, I guess, not the opposite view [19:55:58.0000] I don't think so? [19:56:15.0000] yeah that was a bad way of saying it [19:56:25.0000] 497 aims to eliminate the "set val to val.[[Value]]" part [19:56:32.0000] for my part, I have no issue with that part [20:01:50.0000] In the spirit of Either, I'd like to be able to say (or at least think) this AO returns either an integer or a throw-completion (Either), and have that actually be true, not some waffling about normal completions. [20:02:35.0000] well, my point is, "Either" is neither an integer nor a throw-completion [20:02:46.0000] it's a structure which represents both the "integer" possibility and the "throw" possibility [20:03:07.0000] and my claim is, that is how we ought to think of completion records [20:03:34.0000] hm [20:07:16.0000] I might be okay with that. [20:08:12.0000] except it's not really how we're set up to think of completion records. [20:08:37.0000] "set up" by the prose which introduces them? [20:08:57.0000] that, and the record itself. [20:10:10.0000] e.g. unlike Either, completion records don't have a structural division between the normal possibility and the abrupt possibility. [20:11:15.0000] well, there is an explicit distinction between those whose type is ~normal~ and all others [20:11:29.0000] (in that the latter are defined to be "abrupt") [20:12:09.0000] I agree there's nothing further which distinguishes them in that section, although the `!` and `?` macros further switch on it and thereby emphasize its importance [20:15:28.0000] i'm saying that if you wanted to convey something like Either, you would probably structure Completion Records differently. [20:16:09.0000] ehhhhhh I mean, that's how I would structure it [20:16:32.0000] I might give the `value` field different names in the two cases, I suppose? [20:17:06.0000] but my understanding of Completion Records has always been precisely that they were intended to convey the thing conveyed by rust's Result type [20:17:09.0000] With the TS example, `{ type: 'error', value: E } | { type: 'ok', value: T }`, is there a constraint that the two alternatives must have the same fields? [20:17:33.0000] no, no [20:17:41.0000] *no, there is not such a constraint, in TS [20:18:41.0000] and we could certainly restructure Completion Record so that the two cases didn't share any field names except [[Type]] [20:19:05.0000] it would just be a little wordier, is all [20:21:28.0000] e.g., a completion record is either a 'normal' comp rec, with [[Type]] (=~normal~) and [[Value]] fields, or an 'abrupt' comp rec, with [[Type]] and [[Value]] and [[Target]] fields ? [20:22:29.0000] yup [20:23:37.0000] so backing up... [20:25:25.0000] did you mean that you want to solve 1796 before 545, or just that you don't want 545 to handle returns (until 1796 is solved)? [20:26:08.0000] i.e., the possibility of
s without a 'returns' section [20:26:34.0000] leaning towards the second one [20:26:48.0000] actually I'm pretty neutral myself but I believe that's the position of shu and michael [20:27:21.0000] hm [20:27:26.0000] let me rephrase, I misread your question [20:28:29.0000] simpler: would you like to solve 1796 before anything of 545 lands? [20:28:35.0000] I do not want to block 545 on 1796. both "have 545 include `returns`, with ecmarkup just discarding it" and "have 545 omit `returns`" are viable. I lean weakly towards the second; I think the other editors lean strongly towards the second [20:28:43.0000] simpler: no [20:31:24.0000] 1796 might be easier to solve once 545 is in place. [20:31:29.0000] yup, agreed [20:33:00.0000] on that note: I did a bit of work today on a branch of ecmarkup for use in 545 [20:33:06.0000] (which is what prompted this whole thing) [20:33:38.0000] currently it consumes-and-discards the 'op kind', 'name', 'for', 'returns', and 'also has access to' fields [20:34:00.0000] currently, if my '545' code sees return info in the preamble, it puts it in the
'returns' section and sometimes removes it from the preamble (so it doesn't appear in the description). If ecmarkup simply discards 'returns' section, that would (currently) omit info from preamble. [20:34:19.0000] yeah, best to leave it in the preamble for now, I think [20:34:31.0000] in the "description" field [20:35:30.0000] Something to watch for when you're diffing the generated preambles (in case I forget) [20:35:36.0000] yup yup [20:36:30.0000] anyway, I'll have a branch tonight which parses the h1 and the 'parameters' and 'description' fields and generates approximately the right output [20:36:41.0000] cool [20:36:50.0000] though, again, only for basic AOs, not builtins or any of the other kinds of things [20:38:07.0000] and I'll bring up the issue of what to do with parameters again at the editor call on Wednesday [20:38:28.0000] we discussed it last week and were in favor of your multiline thing but the issue of optionality had not occurred to me at that point [20:39:06.0000] I'm ok with leaving out builtins, but i'd like the other operations (SDO, numeric methods, record methods, internal methods, ...) [20:40:20.0000] as for optionality, the semantics of square brackets are fairly different for AOs vs built-ins [20:41:04.0000] For built-ins, everything is optional, square brackets just tell you what the 'length' is. [20:41:22.0000] (if it isn't explicitly specified) [20:41:39.0000] hmmm, so, let's go through the other things more concretely [20:42:06.0000] numeric methods I'm totally fine with; they're pretty much just AOs, from my perspective, just with unusual names and with an additional calling convention [20:42:24.0000] (For AOs, square brackets are the difference between a spec error or not.) [20:42:27.0000] none of the SDOs currently have headers, so I'd probably want to start by adding them [20:43:38.0000] preambles you mean? [20:43:39.0000] concrete methods are consistent as of 1994, so I'm happy to include those as well [20:43:44.0000] yes, sorry, preambles [20:45:14.0000] It seems a bit odd to me: introduce prose, which then has to be converted to
, as opposed to just starting with a
. [20:45:31.0000] whats all this discussion about 👀 [20:45:35.0000] it's a separation of concerns thing [20:45:39.0000] devsnek: pr 545 [20:45:53.0000] jmdyck: I want 545 to do just one thing, which is a strictly internal reformatting [20:46:00.0000] ah [20:46:44.0000] jmdyck I would also be OK with doing it in the other order: land 545 without SDOs, and then in a follow-up PR add SDOs [20:46:49.0000] I just don't want to do them at the same time [20:46:52.0000] well, ecmarkup could generate the current SDO 'preamble' [20:47:48.0000] true [20:48:08.0000] I'm a bit uncomfortable with just discarding them, though, because that makes it more likely they get stale [20:48:12.0000] (and also makes it harder to review) [20:48:28.0000] wait, discarding what? [20:48:40.0000] the DLs for SDOs [20:48:56.0000] unless you meant a different thing by "could generate the current SDO 'preamble'"? [20:49:33.0000] currently, if an SDO takes a parameter, it has a

With parameter _foo_.

[20:49:49.0000] oh, yeah, I totally forgot about those [20:50:32.0000] sure, I guess, works for me [20:51:00.0000] what would you want done with things which lack parameters? [20:51:03.0000] as in TopLevelVarScopedDeclarations, let's say [20:51:52.0000] in the one-line-per-parameter world? [20:52:17.0000] or parameters-in-dl world? [20:52:25.0000] let's say the parameters-in-dl world [20:52:26.0000] i've lost track [20:53:41.0000] currently, for TopLevelVarScopedDeclarations, I say: [20:53:48.0000]
parameters
[20:53:48.0000]
none
[20:54:52.0000] ok, works for me [20:55:53.0000] right now, the
s for SDOs are all in an annex, because that long predated SDO-consolidation [20:56:35.0000] yup [20:56:53.0000] now that they're consolidated it makes sense to inline them, I would think [20:57:03.0000] concretely, for TopLevelVarScopedDeclarations, I would expect: [20:57:12.0000] [20:57:13.0000]

Static Semantics: TopLevelVarScopedDeclarations

[20:57:13.0000]
[20:57:13.0000]
for
[20:57:13.0000]
Parse Node
[20:57:14.0000]
parameters
[20:57:15.0000]
none
[20:57:16.0000]
[20:57:33.0000] yup, just wanted to see some uptake on 545 before putting in the work [20:58:13.0000] the `op kind` is implied by the "type=sdo" in the `emu-clause`, the `name` is implied by the `h1`, and per above I'm assuming we land 545 without `returns` for now [20:58:15.0000] i had a question on something you said before: [20:58:33.0000] (I'm also not totally sold on "for" for SDOs) [21:00:01.0000] well, there are multiple definitions, and they're discriminated on the basis of Parse Node productions [21:00:33.0000] I agree it's not hugely helpful as is. [21:03:03.0000] anyway, you had a question? [21:05:55.0000] "I want 545 to do just one thing, which is a strictly internal reformatting": currently, 545 will sometimes alter the description in a way that ecmarkup would be unlikely to undo. Are you okay with that, or do you want to first rearrange things so that 545 will have zero rendered effect? [21:06:20.0000] Do you have an example off the top of your head? [21:07:09.0000] not off the top [21:07:34.0000] My answer will depends on how significant the diff is, I think [21:08:37.0000] in the ideal world we'd rearrange things first, but if that's just going to be a bunch of annoying-to-make tiny wordsmithing tweaks I would be OK combining it (though can't speak for other editors) [21:08:47.0000] otoh, if the diff is large, I'd want it split out so it can be considered on its own terms [21:08:56.0000] we did discuss where the
should go, any you said immediately after

, so that would be one example [21:10:17.0000] e.g., if the clause is currently

preamble

, and I change that to

, then ecmarkup will presumably generate

[21:10:27.0000] ah, indeed yes [21:11:44.0000] Stuff like that would be the biggest diffs, I think. [21:12:16.0000] If we're consistent about putting any emu-notes before the preamble, I can just have ecmarkup generate that as the output [21:13:09.0000] I'm pretty sure we're not consistent. [21:14:06.0000] I think for that _particular_ example I'd be happier if we rearranged it as its own PR, just because that kind of change is difficult to review in the generated diff [21:14:12.0000] but we can worry about that when we get there [21:14:27.0000] k [21:14:40.0000] (or at least its own commit, not necessarily its own PR) [21:17:06.0000] oh, one last thing: you have headers for things like Abstract Equality Comparison, which are weird [21:17:23.0000] they are indeed [21:17:24.0000] weird meaning, Abstract Equality Comparison has its own unique calling convention, and a different preamble [21:18:14.0000] you have them labelled as being of kind "abstract operation" [21:18:22.0000] they should at least be their own kind [21:18:33.0000] and possibly not have headers at all [21:19:18.0000] yeah, sometimes it's hard to know exactly what constitutes a 'kind' [21:20:06.0000] There's no reason it couldn't be a completely conventional AO. [21:20:10.0000] yup [21:20:21.0000] except possibly churn elsewhere [21:20:49.0000] it isn't referenced much. [21:20:57.0000] it's discussed in some books and such [21:21:04.0000] which are not easily patched [21:21:57.0000] but if we called it AbstractEqualityComparison or Abstract_Equality_Comparison, I don't think anyone would be confused if a book called it Abstract Equality Comparison [21:22:51.0000] (or we could say that an AO name can have spaces) [21:23:28.0000] yeah, it wouldn't be that bad [21:24:07.0000] books are likely broken already, we've renamed a ton of AOs [21:24:41.0000] i think it matters precisely zero if we break a book that's published months after it's written and is obsolete potentially months before it's published [21:24:54.0000] I care more than zero [21:24:56.0000] are there that many books that actually refer to specific AOs? [21:24:59.0000] but not infinitely [21:25:10.0000] well, abstract equality is a particularly popular thing to talk about [21:25:11.0000] because it's weird [21:25:54.0000] i mean, i don't think we should capriciously break them [21:26:07.0000] but someone who's writing or reading a book already gave up caring about staleness/obsolescence [21:26:42.0000] and most books that talk about it are going to talk about `==` and not the arbitrary name the spec has historically given it [21:35:31.0000] re 497, we're maybe not too far apart. [21:57:08.0000] disagreement seems to hinge mostly on what counts as implicit and how completion records are framed, yes [21:57:53.0000] I am happy to revise the framing of completion records as part of 1796 (or elsewhere) [22:00:18.0000] (also, not gonna have the branch ready tonight, since I still need to teach it how to handle concrete methods and etc) [04:11:36.0000] Hello I see this event "Do Expressions Experiment Planning" on the TC39 events calendar [04:11:37.0000] Did anyone know what's the topic of this event? [06:32:14.0000] Bakkot: forgot to ask: do you (or the other editors) have motivations for structured-headers other than the things I outlined? [08:07:27.0000] jmdyck: my motivation is that i currently scrape the spec to try to get a list of AO names for es-abstract; something that would allow me to reliably identify things that take or return Parse Nodes, for example, would be amazing (since it makes no sense for me to try to support those), and something that let me eventually validate argument and return types would be even better. [08:16:23.0000] That sounds well-aligned with what I'm going for. [09:52:37.0000] https://jsfiddle.net/jgu2a8ef/ This behavior is confusing to me with destructuring. If you uncomment the code d is defined. [09:54:21.0000] I like how it's consistent across FF and Chrome, so it's clearly part of the spec probably. I just can't reason about it. [10:02:34.0000] Sirisian|Work it's the same thing as how `var x = y = z` will define `y` in the global scope [10:03:14.0000] for exactly the same reason, `const validAttributes = { d, ...e } = c` will define `d` and `e` in the global scope [10:03:19.0000] today I learned. I rarely if ever write code like this. [10:05:48.0000] Would be nice to have syntax like const a = { const b, const ...c } = d; I mentioned that the other day without realizing the automatic global scope. [10:06:14.0000] Or I guess it would still be global scope and const in that interpretation. hmm. 2021-03-30 [18:38:54.0000] i'm trying to figure out [18:39:43.0000] so i know mark's scary with/proxy trick [18:39:56.0000] i'm trying to figure out a way to make a sort of [18:39:58.0000] sub environment [18:40:04.0000] inside node [18:40:54.0000] the code i'm running isn't malicious, but i do want to get the environment correct [18:40:59.0000] basically cf worker env [18:43:24.0000] getting the subset of globals was easy [18:43:35.0000] the thing i'm struggling with now is making the global object an event target [18:47:33.0000] `util.inherits(global, EventEmitter)`? [12:19:15.0000] shu: Bakkot: I believe the remove-subclassing change is close to landing in Temporal (https://github.com/tc39/proposal-temporal/pull/1459) heads up if you wanted to take a look [12:19:47.0000] (and if you do, and would prefer the spec changes to be split out for ease of review, ping me and I'll do it)