2021-11-01 [22:47:15.0757] definitely there's lots of spam PRs github hid [22:47:25.0274] where did you get these notifications? i haven't seen any [22:47:44.0686] 1986 got closed because anne had deleted his fork, so the PR couldn't ever be updated [22:48:25.0796] oh maybe i didn't get the notifications because i did the action. [22:49:02.0043] so re PR 1508 - that actually has a ref that points to a3bae8cc2ad9da4db1379cf2af683eb115a65f88 (which is also PR 1378) [22:49:09.0596] * so re PR 1508 - that actually has a ref that points to a3bae8cc2ad9da4db1379cf2af683eb115a65f88 (which is also PR 1378) [22:50:09.0997] all of the spam PRs' refs are still there forever. one of them, 1642, followed the master branch - meaning, even tho the PR is utterly inaccessible, the PR was from master *to another branch*, so every time master changes, the PR ref moves. but now it's closed, so that ref won't keep changing. so that's nice 2021-11-02 [23:28:42.0737] finished my formatter, finally: https://github.com/tc39/ecma262/pull/2564 2021-11-03 [22:32:54.0414] "is finite" seems to be used in the spec for both Number values and also mathematical values. Is that desired? [23:08:01.0958] seems fine [23:08:28.0631] we give the definition for `finite` for Number values, even [14:29:48.0178] gonna be a couple minutes late for editor call, sorry 2021-11-04 [19:25:03.0398] shu: https://github.com/tc39/ecma262/pull/2566 [07:21:53.0122] will look today [12:41:50.0583] shu: re: https://github.com/tc39/ecma262/pull/2548, it looks like very nearly every `!`-prefixed call gets the user-code effect suppressed (possibly actually all of them?). maybe worth building that heuristic into ecmarkup? [13:57:03.0652] bakkot: almost all, yes. worth thinking about building it in. it puts the burden of vigilance on us (the PR reviewers) to remember to check if a `!` shouldn't be suppressed. otherwise it puts the burden on authors [13:57:14.0233] putting it on us is probably the right choice [14:40:46.0069] bakkot: Michael Ficarra oh, for the "*default*" stuff, the point is that "*default*" is used only as a [[LocalName]] and not as an [[ExportName]] in ExportEntry Records, and therefore is not user visible? [14:46:54.0179] so if a module exports a value named `"*default*"`, that could be imported, since the magical [[ExportName]] name is `"default"`, which has always been user exposed? [14:59:13.0612] yeah exactly [15:01:50.0746] (It also gets into the [[BindingName]] of ResolvedBinding Records, but that's basically the same as the [[LocalName]] of ExportEntry Records) [15:03:30.0496] right [15:03:49.0878] whereas `"*"` and `"*namespace*"` leak into [[BindingName]], which is the problem [15:04:13.0456] into [[ImportName]], rather [15:06:06.0263] ah right, that's the usual case [15:06:13.0167] the [[BindingName]] problem is for accessing via a namespace object [15:08:39.0010] ah, yes, right [15:10:12.0697] actually I thinking further I'm not 100% sure `"*namespace*"` is actually a problem, hm [15:11:25.0971] `"*"` definitely is though [15:11:48.0836] why isn't "*namespace*" a problem? [15:12:43.0383] because the lookup that's happening in step 10 of 10.4.6.8 (module NS [[Get]]) is of the post-resolution name [15:12:52.0123] which is strictly internal, same as `"*default*"` [15:13:55.0842] [[BindingName]] tells you where to find the binding of interest _within_ the module; it's not the externally-facing name [15:14:29.0620] exactly the same same as [[LocalName]] of ExportEntry Records [15:14:56.0673] oh, and `export *` has no [[LocalName]] [15:15:12.0753] so if i did an `import "*namespace*"` it would not resolve to the actual NS object, since that has special handling [15:16:02.0503] okay, but also _because_ of the special handling everywhere for NS objects, it's certainly also correct and clearer if we just globally replaced it with `~namespace~` [15:16:08.0401] `export * from 'mod'` has no [[LocalName]], right (none of the `export from` forms do) [15:16:18.0884] (there is no `export *;`) [15:16:26.0094] yes, i meant with the `from` tail [15:16:28.0365] yeah, right [15:30:56.0103] > if i did an import `"*namespace*"` it would not resolve to the actual NS object right, though not because of specially handling `"*namespace*"`; rather, it's because that gets resolved with `ResolveExport("*namespace*")`, which looks for an ExportEntry Record whose [[ExportName]] is `"*namespace*"`, which is not a thing we ever create (except of course with bradley's PR you could make one explicitly) [15:31:24.0801] ah, yes, right [15:32:04.0124] anyways lgtm. further classification of the various meanings of `"*"` is a nice added bonus [15:32:17.0384] if you did `export { f as "*namespace*" }`, then that would resolve to a ResolvedBinding Record whose [[BindingName]] is `f`, so again no problems there 2021-11-05 [10:18:34.0191] ljharb: just marked https://github.com/tc39/ecma262/pull/2566 as ready; it should go in as the current set of commits imo [10:19:24.0501] I kinda want to bikeshed the names further but we should just land it and maybe bikeshed some future day [12:59:11.0114] which names you aren't 100% on? [13:01:51.0552] `all-but-default`, mainly [13:02:42.0681] `export * from 'mod'` is going to _export_ all but the default name, but the way it's implemented is, it asks the upstream module for _all_ of its names, and then filters out `"default"`, so having the [[ImportName]] be `all-but-default` is arguably misleading [13:03:25.0992] ah, i see [13:05:16.0896] sounds like implementation detail, which makes me feel like `all-but-default` is accurate enough (certainly more accurate than `*`). the plumbing of imports and exports is arcana to most people, even those who read the spec regularly [13:05:18.0169] * sounds like implementation detail, which makes me feel like `all-but-default` is accurate enough (certainly more accurate than `*`). the plumbing of imports and exports is to arcanamost people, even those who read the spec regularly [13:05:21.0143] * sounds like implementation detail, which makes me feel like `all-but-default` is accurate enough (certainly more accurate than `*`). the plumbing of imports and exports is arcana to most people, even those who read the spec regularly [13:07:29.0944] ljharb: jmdyck just pointed out a type issue; I'm going to force-push up a fix in a sec [13:16:06.0223] "all-named"? [13:17:42.0019] The problem isn't that "all but default" is awkward, it's that it's inaccurate as a description of what's being imported [13:35:11.0711] which commit do you want the fixup merged into? [14:00:43.0502] the namespace one [15:56:01.0465] bakkot: there's a merge conflict when i reorder the fixup commit to be right after the namespace commit, and it's not super clear to me what the right resolution is [16:14:00.0851] k, will fix [16:16:25.0219] ljharb: updated [16:18:11.0551] ugh, no, I squash two [16:18:12.0736] one sec [16:19:56.0847] k, actually good now [16:52:17.0562] thanks 2021-11-09 [16:42:18.0031] shu: did you want to review https://github.com/tc39/ecma262/pull/2154 ? I rebased and partially rewrote it and Michael reviewed [16:42:32.0518] * shu: did you want to review https://github.com/tc39/ecma262/pull/2154 ? I rebased and partially rewrote it and Michael reviewed [17:11:10.0052] yes i do [17:11:16.0056] and i'll get to it before wed 2021-11-10 [14:31:12.0626] will be a few mins late 2021-11-19 [14:50:25.0895] can call user code is getting there, maybe another one or two sessions to track down false negatives [14:51:32.0675] bakkot: whenever you merge my PR and do the next ecmarkup release, do you mind updating ecma262's package lock as well? [14:51:54.0965] i don't know how to install older versions of npm and also don't want to rewrite the file for no good reason [15:15:57.0080] will do [15:26:53.0601] thank you [15:35:06.0501] shu: https://github.com/tc39/ecma262/pull/2583 [15:55:00.0247] excellent 2021-11-20 [18:13:32.0922] @shu `npx npm@6 install` for future reference 2021-11-24 [14:57:26.0956] https://meet.google.com/qgj-cbjw-qmo 2021-11-29 [13:02:33.0470] I think the thing we should propose is allowing loose matching, as recommended by Unicode [13:03:07.0806] if we do that, we can definitely drop (some of) the tables [13:18:29.0411] as a continued non-user of regexps, sgtm [13:32:26.0006] ugh, no [13:32:29.0411] we should not do that [13:32:43.0376] generally speaking it is bad to have multiple ways to spell the same thing [13:36:51.0174] so... stick with the status quo and everything requires consensus? [15:18:09.0692] update: on the agenda for next meeting: https://github.com/tc39/agendas/pull/1084 2021-11-30 [15:41:43.0645] seems like maybe https://github.com/tc39/ecma262/tree/HEAD/workingdocs should be deleted; thoughts?