2023-01-04 [09:45:05.0354] Rob Palmer: we can discuss our plans in the editor call today, but even if there are no changes to the editor group, it may still be a good idea to have a vote of confidence and give an opportunity for committee feedback on our modus operandi [11:29:44.0386] Thanks Michael. In the past, there has been committee feedback for us to spend less plenary time on meta issues such as elections. So unless there is a specific need for an Editor election, I would suggest not initiating one. How about raising a Reflector request-for-feedback issue for the Editors? [11:59:01.0360] i agree with the request for comments async approach. we can announce the issue in the next editor updates [11:59:20.0374] or better yet, an anonymized feedback form [11:59:33.0112] i'd rather not put folks on the spot if they have criticisms, especially in plenary [12:03:06.0140] instead they should all be given 3 incense sticks that give off distinct colored smoke that represent how pleased they are, they will be asked to form a circle with their backs turned to each other when lighting the incense of their choice [12:03:19.0235] then we will judge what color the mixed smoke cloud is [13:06:20.0773] Rob Palmer: I'm fine with that [15:43:14.0767] Rob Palmer: We'd all like to stay on for another year. Can you create an anonymous feedback submission form for us? 2023-01-05 [17:27:24.0471] bakkot: https://github.com/tc39/ecma262/pull/2973 if you wanna take a look and stamp, should be ready to merge [17:29:03.0859] done [17:34:57.0026] Michael Ficarra: i made a form and shared it with your f5 email, and bakkot 's gmail email [17:35:53.0132] i'll share it with rob too actually [17:37:42.0181] hmm nevermind, i can't. bloomberg.net can't receive collaboration requests for workspace, i guess? Rob Palmer i get "The administrator for bloomberg.net has disabled the ability to receive items from outside their organization. If those you're attempting to share with would like more information, they should contact their organization administrator directly." when trying to add you as a collaborator to the form [07:31:13.0720] yes, our IT folk don't want us polluted by external data. For TC39 work, please use my personal address rob.palmer2@gmail.com [13:59:33.0834] The form looks good. Would you like me to post it to the Reflector? [14:01:00.0082] sgtm, with a short message stating the current editor group is planning to stay for another year, so please submit feedback if folks have'em Michael Ficarra: bakkot ^ 2023-01-11 [08:20:17.0260] shu: bakkot If you can, please take a look at https://github.com/tc39/ecma262/pull/2972#issuecomment-1372894434 before editor call today [08:22:58.0373] I think bakkot opposed using "one of" with multiple-inhabitant types, but if that's not the case, then we just need ecmarkup to support new phrasing [08:34:55.0836] thanks, adding to todos [08:38:03.0770] bakkot: do biblio files loaded later via `--load-biblio` always override entries loaded earlier? [09:04:05.0335] shu: I think so yes [09:04:16.0374] there might be some edge cases; it's not thoroughly tested [09:04:19.0923] but it should [09:07:17.0330] cool [14:29:12.0161] i also dislike "one of" with non-unary or nullary types [14:30:25.0981] if i had to form a rule around it i think i prefer something like "either an A, a X, a Y, or one of *foo*, "bar", or ~baz~" [14:31:01.0273] so you're okay with "either" for more-than-2? [14:32:49.0401] no, it's more like i see the structure as "either {phrase about distinguishing types with >1 values} or {phrase about distinguishing constants}" [14:33:22.0052] i realize that's your point, i'm just asking a side-question. [14:33:30.0090] ah [14:33:40.0671] * i realize that's your point, i'm just asking a side-question. 2023-01-16 [13:41:31.0024] i'm planning to ask for stage 2 for the get intrinsic proposal after i make a few spec changes. https://github.com/tc39/proposal-get-intrinsic/pull/15 is one of them. i'd love editors' thoughts on it 2023-01-18 [14:19:11.0014] i merged that, and https://github.com/tc39/proposal-get-intrinsic/pull/16 is the next one 2023-01-19 [22:41:03.0293] k, merged that, and now https://github.com/tc39/proposal-get-intrinsic/pull/17 - this is hopefully the final form of the proposal, so i'd love thoughts on that :-) 2023-01-20 [10:20:37.0697] I'm just noticing that we link things like "is a Number" and "is not a Number", but miss cases like "is either a Symbol or a BigInt" [10:20:51.0057] not sure what we could do to make that work though [11:36:30.0413] link `either a symbol` and `or a BigInt`? [14:41:28.0030] but then in "either a Symbol, a String, or a BigInt", you wouldn't get a link for "a String". So maybe just link "a Symbol", "a String", and "a BigInt". [14:41:57.0140] That would create links in a lot more spots, but maybe they're places you'd like links anyway. [14:47:52.0688] ah yes, good point [14:48:06.0883] then `is a Number` should probably only link `a Number` [14:49:19.0855] Yup, could change `` to just `` 2023-01-23 [12:43:03.0263] ping bakkot shu on https://github.com/tc39/ecma262/pull/2972 [12:43:27.0273] please review so we can get that and #2877 merged 2023-01-25 [10:54:42.0080] this highlighting is a problem: [10:55:06.0545] we really need to go through and eliminate shadowing in ACs [11:14:55.0734] It's debateable whether that's shadowing, because it's in an AC, which doesn't 'inherit' any aliases from the surrounding scope, except what's explicitly captured. [11:41:07.0718] whatever we call it, it's not the same variable but is being highlighted as if it was [11:41:30.0940] it's not worth the impl effort to have ecmarkup distinguish them, we should just change the name [11:53:37.0633] Agreed they're distinct variables, but they're bound to the same execution context, so maybe it's okay that they're highlighted at the same time. [12:05:31.0172] i agree with michael here [12:05:36.0621] i use the highlighting feature to eyeball use sites [12:05:45.0823] this is more misleading than helpful [12:08:27.0164] use of the alias, not use of the EC? [12:16:32.0205] yeah, definitely [12:16:59.0171] (well, I was asking shu) [13:24:10.0080] jmdyck: EC? [13:24:30.0381] i meant use of aliases is what i most frequently use the highlighting feature for [13:25:30.0367] EC= execution context. I was asking if "use sites" meant use of the alias, and not use of the thing it referred to. [13:29:02.0156] oh, yes, i meant use sites of the alias [13:29:12.0978] ok, thanks. [15:58:07.0228] ljharb: https://github.com/tc39/ecma262/pull/2877 is rebased and ready to go [15:58:23.0605] it should land as one commit 2023-01-26 [16:03:05.0470] sounds good, I’ll land that in a few hours [14:06:45.0443] having reviewed https://github.com/tc39/ecma402/pull/749 , all traces of my uncertainty regarding the ECMA-402 [[<_alias_>]] Record field indirection are gone. The patterns it has enabled are atrocious. [15:08:54.0283] shu: do you care to review https://github.com/tc39/ecma262/pull/2898? it's good to go otherwise I think [15:32:56.0843] bakkot: glancing at it, i think i would 2023-01-30 [07:03:04.0826] btw i have a conflicting meeting at 830-900am PT i have to drop for, in case the editor updates happen at that slot