2023-03-01 [18:13:31.0968] thanks, I responded [21:59:42.0867] any thoughts on https://github.com/tc39/ecma262/issues/3020#issuecomment-1441743282 ? [09:57:21.0034] yeah I think they're right and the solution is indeed to move the step into the derived path [11:25:01.0383] that was what i was suspecting but i find it hard to believe nobody would have noticed that while implementing class fields [11:30:46.0508] why is that hard to believe? 🙃 [13:29:01.0785] Is it possible that implementations are inefficient today due to the double init? [13:30:11.0568] no, looks like no implementations do double init [13:30:23.0740] purely a spec bug [14:32:18.0333] Is there a meeting? [14:33:21.0393] yes [14:35:19.0930] "Sorry, we encountered a problem joining this video call." [14:38:04.0737] The URL is the one that ends in pcz? [14:41:35.0698] yes [14:42:40.0869] then I guess google just doesn't like me any more. [15:00:27.0564] that's very strange. are you logged in to the google account on the invite? [15:00:41.0206] (i'd still expect you to be able to get to it if not, to be clear) [15:01:07.0491] I don't think I ever got an invite [15:06:53.0942] Apparently, being logged into google made the difference. [15:07:36.0994] But I'm pretty sure it hasn't been necessary in the past. [15:14:38.0578] yeah it shouldn't be [15:25:00.0482] I was logged out when I initially attempted to join, and it let me put a name in and ask to join (I didn't, I logged in, but it would have let me) [15:25:30.0018] That's normally what I get. 2023-03-02 [18:11:24.0719] I can't stop thinking about identity 😩 [20:12:11.0832] go on a bike ride [20:12:13.0692] live in the moment [20:12:17.0817] your identity is your own [21:48:52.0293] be grateful nobody's trying to abbreviate it in the spec and figure out the capitalization :-p [21:48:55.0631] * be grateful nobody's trying to abbreviate it in the spec and figure out the capitalization :-p [09:03:03.0494] i get that reference and am triggered 2023-03-04 [06:51:43.0992] Github says "Now, GitHub will help potential first-time contributors discover issues labeled with (good first issue)", but ecma262 has the (good first patch) label instead. Is that because we don't want GitHub's help? [12:27:54.0654] no, it’s just that the label predates github supporting it 2023-03-07 [08:59:03.0187] let's rename it [08:59:06.0231] I'd love some new contributors [09:07:56.0516] re new contributors, note that https://github.com/tc39/ecma262/pull/3025 is the person's first ever PR 2023-03-08 [14:32:19.0914] waiting for people to get out of meeting room, will be a minute 2023-03-09 [16:31:48.0405] https://github.com/tc39/ecma262/pull/3027 interested in thoughts 2023-03-10 [13:45:57.0570] any thoughts on jmdyck's comments on https://github.com/tc39/ecma262/pull/2997#pullrequestreview-1335591901 before i merge it? [14:13:32.0037] (I didn't notice that it was already 'ready to merge'.) [14:30:50.0236] I'm fine either accepting them before merge or asking jmdyck to submit a separate PR for them [14:31:05.0253] they don't hurt but also aren't necessary to merge [15:21:24.0081] if the suggestions are good as is, i can pull them in as part of rebasing 2023-03-11 [19:23:28.0228] yeah they're fine 2023-03-13 [09:32:28.0407] we should discuss Istvan's email at the beginning of the next editor call [10:44:13.0258] what email? [12:18:30.0814] why does he need that info in his slides? both 262 and 402 have separate items for that [12:18:57.0294] maybe "Thanks! There's no need to mention either, though, since we both have individual agenda items for that exact purpose." [12:27:07.0513] I don't know, we should talk about it [14:13:44.0910] test [14:37:18.0190] i kept getting "cannot send message" [14:37:45.0140] why don't we just use discord or something, actually? [15:03:41.0643] oof, discord's UX is horrific [15:10:27.0057] i'll tell you what else is horrific UX, not being able to send messages [15:11:40.0686] ha, true enough [15:13:37.0956] but i don't use discord either actually [15:30:11.0439] > <@shuyuguo:matrix.org> why don't we just use discord or something, actually? we couldn't get them to update their terms of service to allow public logs, which are a requirement from the lawyers [15:30:28.0773] personally I would be happy to go back to irc, but alas [15:30:32.0940] me too [15:30:45.0685] ah yes i remember the log thing now [15:30:51.0662] i had stricken that whole episode from memory [15:34:42.0742] it was Feb 2020, so our focus shifted pretty abruptly right afterward 2023-03-15 [14:36:48.0676] my comcast *and* verizon is down rn so i won't be in the call, lmk if there's any repo stuff [15:14:30.0264] ljharb: We're trying to get the symbols as weakmap keys PR in this week. We'll ping you when it's ready. Can you be on the look out so we can get that merged as soon as it's ready? [15:37:58.0192] will do [16:13:47.0134] Michael Ficarra: bakkot https://github.com/tc39/ecma262/pull/3027 PTAL [16:17:46.0577] nice, I like it [16:25:23.0883] okay let me rebase #2777 on top of this [16:27:17.0514] okay so the important part of the PR is `Note that Symbols produced by Symbol.for are a special case; they have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language.` [16:27:37.0056] I don't know if the reader knows what "but do not have identity from the perspective of the ECMAScript language" means [16:27:45.0458] * okay so the important part of the PR is "Note that Symbols produced by Symbol.for are a special case; they have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language." [16:27:54.0786] i'd say there're 2 important parts: 1) rejiggering the definition of identity to be about "comparison for equality" in the abstract instead of defining an operation over the word "is" and 2) that sentence [16:28:08.0818] I think we should probably talk about what the *consequence* is instead [16:28:19.0362] the consequence? [16:29:57.0285] think the practical consequence is... you keep using the word "identity" as you understand it, and i correct you where i think we need to distinguish Symbol.for [16:30:02.0949] which should be exceedingly rare [16:30:29.0216] also it talks about language values as if they're not specification values, but we mix them so thoroughly that I don't think we should really avoid that reality [16:31:19.0446] what [16:31:33.0696] we say "specification or ECMAScript language value" all the time [16:31:44.0029] or am i misunderstanding what you mean by mixing [16:32:21.0679] we do? [16:32:32.0195] not that I see [16:33:41.0208] "Types are further subclassified into ECMAScript language types and specification types" [16:33:48.0017] what do you think that sentence means [16:34:42.0937] like, there's a list of language types, which are inhabited by the language values [16:34:47.0627] and the other stuff are specification types [16:34:49.0321] and spec values [16:34:56.0743] what do we call the type of all values used in the spec? [16:35:08.0905] I have been calling that specification values [16:35:08.0972] i don't think we have need of that word [16:35:16.0272] that is not what specification values as used means [16:35:32.0016] i guess those are just "values" simplicter [16:36:28.0652] "A specification type corresponds to meta-values that are used within algorithms to describe the semantics of ECMAScript language constructs and ECMAScript language types." [16:36:37.0949] I see [16:42:28.0386] with that clarification, any other concerns? [16:43:57.0399] I'm writing a suggestion [16:45:11.0184] I'm thinking something along the lines of "Note that Symbols produced by Symbol.for are a special case; they are compared for equality as if they did not have identity from the perspective of the ECMAScript language." [16:45:55.0093] but then also if we say that they do not have identity from the language perspective, and symbols have no qualities other than their identity, shouldn't the language think that all Symbol.for symbols are the same? [16:46:29.0671] well this is where we fucked up with designing symbols [16:46:35.0461] Symbol.for symbols are really nothing like Symbols [16:46:41.0209] regular Symbols have no other qualities than their identity [16:46:48.0986] Symbol.for symbols have the quality of their string contents [16:46:56.0653] (from the perspective of the language) [16:46:57.0370] symbols have descriptions [16:47:00.0740] not just identity [16:47:08.0551] okay so they will have a unique [[description]]? [16:47:18.0034] and conveniently, all Symbol.for descriptions are unique [16:47:19.0479] so yes [16:48:17.0174] in fact i wonder if that would be an editorial improvement [16:48:19.0584] shu: what do you think about my suggestion? [16:48:54.0773] (regular symbols also have descriptions, which is a quality other than identity, so "regular Symbols have no other qualities than their identity" isn't true - it's just that they have identity _as well as_ descriptions) [16:48:56.0079] wfm, only quibble is i'd move "from the perspective of the ECMAScript language" to the start of the second clause [16:50:03.0973] bakkot: they may not have a description though, in which case the only thing distinguishing them is their identity [16:50:15.0038] but all Symbol.for symbols certainly do [16:50:18.0779] descriptions don't distinguish them but it is a quality they have [16:50:24.0884] but as long as smybol.for symbols all have descriptions and they're all unique, we're good [16:50:37.0021] that is the case, yup [16:50:54.0984] I don't love the "they are compared for equality as if they did not have identity from the perspective of the ECMAScript language" suggestion though [16:50:55.0408] it is an editorial change if we got rid of the global registry for Symbol.for, tagged those Symbols with a special brand, and then compared Symbols with those brand using their [[Description]] [16:51:26.0579] * it is an editorial change if we got rid of the global registry for Symbol.for, tagged those Symbols with a special brand, and then compared Symbols with that brand using their \[\[Description\]\] [16:51:33.0879] Michael Ficarra: maybe you can say more why you don't like the sentence as is [16:51:36.0079] specifically I don't love that suggestion because it de-emphasizes the important part, which is that Symbol.for symbols can be manifest merely by reference to their qualities [16:52:08.0772] in ES code, but not in the spec [16:52:28.0591] that is what "have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language" means [16:52:38.0901] but it is not what "they are compared for equality as if they did not have identity from the perspective of the ECMAScript language" means [16:53:44.0872] bakkot: well that's why in my original approach that's basically what I said [16:54:05.0669] we are going with Shu's approach though [16:54:17.0745] so that is why I like the thing currently in the PR, and not the thing you suggest [16:54:37.0399] I thought we were going with a hybrid [16:54:50.0728] uh [16:55:07.0851] ok we don't need to resolve this confusion [16:55:24.0172] the important part is: I like shu's PR as-is, for the reason I gave above, and do not like your suggested change to it [16:55:27.0406] we are going with 1) clarified definition of identity to add explanations about "from the perspective of" and 2) a separate predicate that enumerates what can be a weak target [16:55:33.0398] were we not planning on still pulling in https://github.com/acutmore/ecma262/pull/3/files? [16:55:51.0943] yes, Ashley's PR already has that predicate [16:55:56.0117] yes we are [16:56:02.0690] I'm only talking about shu's PR right now [16:56:04.0148] and my PR adds context onto it, that's all [16:56:07.0519] well, not the changes to the identity section of that PR [16:56:10.0649] the rest of it yes [16:56:26.0293] yes, the changes to the identity section just reverted Ashley's changes, they weren't a suggestiong [16:56:31.0673] * yes, the changes to the identity section just reverted Ashley's changes, they weren't a suggestion [16:56:57.0172] ah okay, then yes [16:57:03.0596] okay so back to bakkot "specifically I don't love that suggestion because it de-emphasizes the important part, which is that Symbol.for symbols can be manifest merely by reference to their qualities" [16:57:19.0217] considering we will provide that information in context, do you still feel that way? [16:57:29.0306] i do now that kevin points it out [16:57:42.0213] yes [16:57:55.0448] the main reason i started down the stratified identity path is because i think identity is the salient concept, and it should be explained at the site of that concept [16:59:16.0512] the location in the text of the predicate can then be purely about describing the behavior by enumerating what can be a weak target; a note can lead back to the identity section that explains the rationale 2023-03-16 [17:00:33.0177] I gotta run off for the next ~30m [17:00:35.0195] Okay how about "Symbols produced by Symbol.for are a special case: from the perspective of the ECMAScript language, they may be manifest at any point using their description, so they are compared for equality as if they did not have identity."? [17:00:44.0606] that wfm [17:00:53.0088] maybe [17:00:58.0140] i don't like "as if" [17:00:58.0978] will think about it when I get back [17:01:02.0523] they literally do not have identity [17:01:36.0433] Symbols produced by Symbol.for are a special case: from the perspective of the ECMAScript language, they may be manifest at any point using their description, so they do not have identity when compared for equality. [17:02:00.0866] they are values with identity but the strategy used for comparing them does not observe the identity, it follows the other path [17:02:19.0691] i disagree [17:02:24.0740] we could say something like "their identity does not participate in the comparison" or something [17:02:39.0292] i think if we say that, we should go back to actually defining the stratified identities [17:03:02.0855] if we're sticking with a single notion of identity as about equality, but there are different equalities that operate at the language level vs the spec level [17:03:06.0639] there is no "as if" [17:03:17.0229] we defined values to have identity or not have it wrt a particular comparison operation [17:03:23.0421] at the language level, they do not have identity [17:03:56.0902] I don't know how we can say, in the previous sentence, that all Symbols have identity, then try to say that these *do not*. They can just have identity and be treated as if they didn't, what's the problem? [17:04:25.0293] okay, then we can say "(with the following exception)" in the previous sentence [17:04:51.0883] > we defined values to have identity or not have it wrt a particular comparison operation I don't interpret it that way [17:05:00.0257] i do? [17:05:06.0229] * > we defined values to have identity or not have it wrt a particular comparison operation I don't interpret it that way [17:05:12.0829] dunno what to tell you, this is the start of our disagreement [17:05:32.0408] and we seem to have lost the agreement that there are in fact 2 identities [17:05:33.0996] can you point to where it says that? [17:06:20.0691] i say: "When comparing for equality, values fall into one of two categories." [17:06:42.0484] formally, i mean: values are categorized as having or not having identity, parameterized by the equality operation [17:06:47.0346] i.e. "when comparing for equality" [17:07:05.0259] there are two levels of "when comparing for equality". at the spec level, with "is" and "contains", and at the language level, with SameValue [17:07:57.0020] it so happens this distinction is not useful at all almost all the time, except the few places we talk about Symbol.for [17:08:13.0552] so i agree it's confusing to actually two concepts, and instead just add a paragraph that calls out the one place where it differs [17:08:39.0749] okay, the way I read that is that equality operations, whether they be "is" or "SameValue", are defined piecewise over two pieces: values with identity and values without identity [17:09:00.0230] that is not my intention, and that is why i split the paragraphs up the way i did [17:09:42.0240] let's see... 1) do you agree my reading is fine and 2) any suggestions on how to make that reading clearer? [17:12:13.0575] I think we've arrived back at where we were last week. I desire for any quality called identity to be an intrinsic and permanent property, not one that is bestowed on it from the outside in some way. [17:12:35.0537] that's why we settled on the two identities approach being acceptable, even if undesirable because of potential naming confusion [17:12:48.0824] you have a permanent and intrinsic property at each level that do not interfere with each other [17:13:19.0525] moreover, how that property is defined is exactly the same across both levels [17:13:34.0306] it's not intrinsic if it depends on the lens through which you're currently looking at it [17:13:37.0622] i think what you are saying is you desire for "identity" to be entirely axiomatic [17:13:51.0514] it is intrinsic [17:14:03.0071] i'm sorry i don't understand your hangup here [17:14:58.0057] the compromise we reached in the call, i thought, was that we stick with the formal underpinnings of 2 identities, but we just don't call it two different things because the difference is not useful almost all the time [17:15:26.0176] like, the spec necessarily works in 2 layers: the meta spec layer, and the language layer [17:15:31.0984] that doesn't make the language layer less intrinsic [17:16:19.0563] Let's say that the way you formalise identity is through a predicate called `HasIdentity`. If I ask whether something has identity, I need to consult the predicate. I can't just observe the thing and tell. I think that's an inappropriate way to define identity. This hang-up is uniquely about identity because it is the basis of reasoning. [17:17:14.0065] i say that is a ill-formed question to ask [17:17:51.0626] there is no singular identity to ask of an ECMAScript language value, there are necessarily two questions [17:18:00.0048] now we're talking about the identity of the concept of identity [17:18:03.0046] does it have an identity in the spec meta-machinery and an identity in the language [17:18:04.0164] no we're not [17:18:06.0991] there literally is one true identity [17:18:09.0071] concretely, consider a real implementation [17:18:15.0409] i do not ask "do strings have identity" [17:18:29.0104] i ask "does the C++ implementation of JS strings have identity? (yes, they are heap objects)" [17:18:40.0019] or i ask "do JS strings have identity?" (no they don't) [17:18:48.0398] i do not ask "what is the one true identity-ness of strings" [17:18:53.0167] that question doesn't make sense [17:19:13.0673] yes but we are living in the world of spec text, so identity must mean spec identity [17:19:37.0858] okay, then you would in fact prefer that we _do_ define "language identity" as a separate thing [17:19:44.0488] which i feel is important to define for the liveness definition [17:19:58.0709] and not just use "from the perspective of" language [17:20:43.0433] yes, it is unfortunate that the concepts would be named similar things and also be so closely related, but that seems like the only way to satisfy both of us [17:20:43.0783] > yes but we are living in the world of spec text we aren't, just like in a C++ implementation we don't just care about the identity of the C++ structures [17:20:48.0944] it's a spec text that specifies a language [17:20:55.0552] a surface language [17:21:14.0022] like i don't know how you think about language specifications if you think concepts should pierce the meta-language and surface-language layer [17:21:17.0052] that seems untenable [17:21:31.0863] no, I think *all* concepts are meta-language concepts [17:21:43.0517] and surface concepts aren't directly discussed, they just arise from meta-language [17:22:12.0114] like ECMAScript language values are values within our spec universe [17:22:32.0389] they're just also 1-to-1 with values that are observed within our fiction [17:22:33.0205] that is true in a fundamental way, but that does not mean the surface-language layer concepts cannot be named and have correspondingly close names! [17:22:49.0606] of course, you're correct [17:23:01.0094] they can have close names, it's just a bit unfortunate, that's all [17:23:19.0878] like it's really really hard to not name them when talking about properties like liveness [17:23:28.0521] that's why I was okay with your PR, but I just thought that the naming was unfortunate (and don't really have a better alternative) [17:23:33.0810] to the point where we do our readers (well, our implementers) a huge disservice [17:23:42.0092] because they are thinking about what optimizations and GCs are allowed [17:24:39.0727] I'm still not entirely sure why you weren't okay with instead having the pair of (suitable for use in a weak map, true spec identity) instead of introducing language identity [17:24:47.0858] * I'm still not entirely sure why you weren't okay with having the pair of (suitable for use in a weak map, true spec identity) instead of introducing language identity [17:24:57.0149] because it made me realize the liveness definition is wrong [17:25:04.0273] or at least, very misleading to me [17:25:10.0758] even if incidentally correct because the domain happens to have been restricted [17:25:11.0821] but can't the definition refer to that pair? [17:26:09.0275] i guess it bottoms out that our mental model of like, the fundamental meta-spec level ontology (or something?) of the spec are very different [17:26:20.0250] and we cannot convince each other [17:26:29.0512] (for why i'm not okay with the pair) [17:28:02.0888] I very strongly vote for keeping shu's PR as-is, no matter how unsatisfying michael finds it [17:28:06.0915] > no, I think all concepts are meta-language concepts this seems to be the crux of it. i most definitely do not think that, nor does the spec as it's been written [17:28:40.0509] I don't think we're going to resolve our different ways of looking at this and don't want to spend more time on it [17:29:06.0762] fair, wfm of course, i want to get back to rebasing 2777 [17:29:07.0052] bakkot: did you read the conversation? I think we've resolved it in the same way we resolved it last time. [17:29:10.0683] (though I'm fine with adding the "with the following exception" bit) [17:29:28.0712] Michael Ficarra: but kevin also didn't like the extra s [17:29:30.0874] Michael Ficarra: I did read it and it did not seem resolved? [17:29:48.0215] yeah I really do not want to define two notions of identity here [17:29:51.0620] and i tend to agree, it doesn't really help readability [17:29:53.0317] I want exactly the thing in the PR [17:31:09.0134] I can't accept something that defines values with conditional identity. The equality operation can be conditional, but identity must be innate and immutable. [17:31:23.0097] I think at some point we are going to have to say too bad and land something [17:31:23.0790] michael it is not conditional [17:31:55.0492] yeah i think i'm doing arguing this, let me add the (with the following exception) [17:31:56.0997] identity that depends on the lens through which you are looking at it is conditional in my book [17:32:11.0744] then you should correct your thinking :) [17:34:10.0307] I am not unique in this! I've read a ton on philosophy of identity recently and this is consistent with basically everything I've read. You need identity to be a foundational concept of what *is*, and you can build everything off of that. You can't define it through some predicate or differently based on context, because then how do you even talk about it being that thing? [17:34:42.0754] my brother in christ i work with compiler writers, not philosophers [17:34:54.0407] yes, this document is not for philosophers [17:35:04.0698] also it just... _is_ conditional? we've said that "does not have identity" means "can be manifest purely by reference to its qualities", and that is true of Symbol.for symbols within the language but not within the specification [17:35:06.0284] yes, but they can teach us some things about building formal logical systems [17:35:17.0932] michael [17:35:20.0791] only if we use language in a way that will be coherent to the people who we are addressing [17:35:22.0948] i also regret to inform you you work on javascript [17:35:24.0209] which is not philosophers [17:35:26.0788] not the lambda calculus cube [17:40:12.0705] okay i applied all other comments except the last sentence one, so should be gtg. let me continue with rebasing 2777 now [17:42:08.0765] when it comes to these really foundational concepts that the rest of the spec depends on, I think it's fair to try to be rigorous and principled [17:43:40.0395] i think we are very rigorous here [17:43:45.0477] the actual rigor is there are 2 identities [17:43:55.0689] we find it editorially confusing to surface that foundation with 2 different dfns [17:44:07.0942] so we use one word, identity, because in all cases the truth tables they produce are the same [17:44:14.0310] where the truth tables differ, we use a sentence [17:45:33.0517] then why do we have to use identity in that sentence? [17:45:48.0352] which sentence? [17:46:15.0234] is it not the final sentence of the identity section that you were talking about? [17:46:19.0081] are you asking why an english sentence can be ambiguous without context, but also disambiguated with a following sentence? [17:47:21.0841] If you're talking about the final two sentences of the identity section, there is nothing ambiguous, there is just a contradiction. [17:47:40.0356] okay, i see i am not getting through [17:47:42.0702] protest noted [17:47:46.0393] i think you're overruled michael, sorry [17:48:11.0346] i would like to finish this PR and go home [17:49:50.0437] I'm gonna stamp it [17:51:36.0510] I am very much not okay with this. I feel this is akin to willfully introducing a spec bug. [17:54:20.0827] We've had plenty of disagreements, but we've always been able to resolve them amicably after some work. I don't think we have any fundamental unresolvable differences here. We even had working solutions! I don't know why we would move forward like this. [17:54:45.0442] We do not have a working solution [17:55:00.0442] After multiple hours of time spent on this [17:55:18.0770] I do not expect we will come to an agreement within another two hours of conversation and I am not willing to spend that time [17:55:21.0358] it's a good test of the escalation path of having an odd-numbered editors in the group [17:55:45.0464] we have talked about not requiring unanimity [17:57:28.0653] i don't see why it's not amicable either, it's just we failed the converge with a compromise? [17:57:34.0231] like i'm not gonna be harboring grudges [17:57:57.0423] Yes, I think it's good that we can resolve small disagreements where no one is particularly passionate. We've done that many times in the past. But I've stated multiple times that a hard requirement for me was for *some* concept to exist (it would be nice to call it identity) that can be used to distinguish any two values in our spec universe, and that concept had to be innate and immutable. [17:58:37.0268] "identity from the perspective of the specification" is that thing, no? [17:58:41.0202] The "two identities" solution satisfied that [17:58:47.0769] we still have the two identities solution! [17:58:51.0276] there's just no s [17:59:39.0572] we have two comparisons [17:59:42.0448] which is a fine thing [17:59:51.0339] but we also have conditional identity [17:59:55.0490] which is not fine to me [17:59:57.0621] arghghhhh [18:00:01.0820] we have two identities [18:00:05.0690] not a conditional identity [18:00:22.0065] "they have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language" [18:00:29.0810] reusing the same english word "identity" doesn't mean the underlying mental model has conditional identity [18:00:34.0444] i will try one last time [18:01:11.0490] consider the s to be "identity from the perspective of specification" and "identity from the perspective of ECMAScript language" that correspond exactly to specification identity and language identity [18:01:40.0317] almost all the time, it is unambiguous which one "identity" talks about, or it literally doesn't matter, so consider the english word "identity" be an elision for one of the two s [18:01:52.0870] where it is confusing, we spell out the full thing [18:01:58.0784] and it is confusing in exactly one place [18:02:34.0000] this is not an any less rigorous or any less formal [18:02:36.0690] but it is more readable [18:02:54.0468] * this is not an any less rigorous [18:03:02.0552] > and it is confusing in exactly one place a note in the liveness section? [18:03:24.0219] in the CanBeHeldWeakly section [18:03:39.0705] though liveness could use a note as well, though we discussed already multiple times, it actually doesn't matter there [18:04:04.0412] with my changes, that section doesn't use identity [18:04:35.0875] my current rebase takes your changes as is, except it refers to identity in the note [18:05:04.0954] I am fine with dropping the reference to identity within the note, if that would help? [18:05:15.0258] * I am fine with dropping the reference to identity within the note in CanBeHeldWeakly, if that would help? [18:05:41.0673] i'd like it there [18:06:29.0288] okay then I don't understand what your object was to my suggestion of "comparing as if they don't have identity" [18:07:19.0691] if we don't use the identity itself anywhere, and we just use comparison operations that are parameterised by its existence/non-existence, then that should be fine [18:07:46.0477] what do you mean by "don't use the identity itself anywhere", including in the note? [18:07:54.0206] let me actually upload the PR and we can go through that [18:08:28.0283] yeah I don't see a reason why the CanBeHeldWeakly note would need to refer to the identity itself [18:08:36.0699] already in my PR I made it so that it doesn't [18:08:53.0392] yeah it doesn't need to [18:09:11.0666] the reason is i think it captures the rationale. if we don't say that we might as well remove the whole note [18:09:38.0896] I would like to see your alternative note [18:10:02.0637] I think my edit to the note captures the entire rationale [18:12:17.0238] hmm [18:12:19.0229] https://github.com/syg/ecma262/commit/dece95561adbd5d1ef994f32a3f95e6da53ef37e [18:12:29.0437] i can't figure out how to create a clean PR against acutmore's branch [18:12:33.0764] but that commit has it in my repo [18:17:07.0808] i can live with dropping referencing "identity from the perspective of the ECMAScript language" as long as we leave the manifestability phrase in there, and keep it as the same phrase as the one used in the identity section [18:18:46.0372] If we drop "identity from the perspective of the ECMAScript language", would we also be able to rephrase the last sentence of the identity section to just talk about equality comparisons as I suggested? [18:19:16.0402] what was your suggestion, the "as if"? [18:19:22.0815] yes [18:19:24.0718] i'll explain again why i have issue with "as if" [18:19:45.0852] > almost all the time, it is unambiguous which one "identity" talks about, or it literally doesn't matter, so consider the english word "identity" be an elision for one of the two s first, recall that this is the mental model i intend ^ [18:20:37.0890] in "comparing as if they don't have identity", i find it difficult to interpret, and ambiguous whether it is spec identity or language identity that is "as if without" [18:20:49.0595] I am fine with having the manifestability phrase, and I see why you want it to be the same as the identity section, but I also think it's as clear as talking about *how* that happens (lookup in the GlobalSymbolRegistry) [18:21:11.0944] i disagree on the clarity of how it happens [18:21:15.0729] the how is the implementation detail [18:21:20.0925] * I am fine with having the manifestability phrase, and I see why you want it to be the same as the identity section, but I also think it's not as clear as talking about _how_ that happens (lookup in the GlobalSymbolRegistry) [18:21:29.0187] anyway that's a tangent [18:21:52.0304] to go back to the "as if" thing, the "as if" phrase begs the question that there is a singular identity that pierces the meta-language veil, as you originally prefer [18:22:13.0183] which is not the mental model that we have [18:22:36.0111] yes, you essentially "look up" the comparison operation based on which identity you're looking to operate on [18:23:11.0593] that doesn't seem like a great thing to do when it can be ambiguous at times! [18:23:25.0327] it's the other way: the comparison determines the identity you're using [18:23:41.0169] i don't have a value and just be like "let me contemplate its identity" [18:23:50.0253] it's always driven by what comparison operation you're doing [18:24:26.0100] anyway i'm not rexplaining the whole thing again, i don't have time [18:24:44.0526] but in the note you wrote, you do discuss whether something has identity or not, which is not just a comparison [18:25:13.0934] what [18:25:50.0552] "has/has not identity" == equivalence classes for comparison operations [18:26:19.0320] are you really confused by the phrase "has identity" used without direct juxtaposition with a comparison operation? [18:28:17.0377] that said i am fine with saying "they have identity from the perspective of "is" and "contains", but do not have identity from the perspective of SameValue"? [18:28:23.0666] is that the confusion? [18:28:56.0410] yeah possibly [18:29:04.0227] > that doesn't seem like a great thing to do when it can be ambiguous at times! I don't think it can be ambiguous? in the spec, you are always comparing from the perspective of the spec. in ES code, you are comparing from the perspective of ES. that's what "from the perspective of" means. there is never any ambiguity about whether you are reading the spec or ES code [18:30:01.0262] anyway i'm going home [18:30:16.0080] the rebased 2777 is up at https://github.com/syg/ecma262/tree/symbols-as-weakmap-keys [18:31:30.0660] I will un-stamp shu's PR for now but if we don't have something which satisfies everyone by EOD tomorrow I'm re-stamping so we can get 2777 landed [18:31:41.0574] and so we can stop talking about this [18:31:57.0729] it is just not worth spending this amount of time on this question [18:37:49.0408] Here is another analogy: the spec could, in principle, define strings as Lists of code units, and replace all uses of "is" on strings with SameValue, and change the SameValue algorithm for strings to be "if x is y, return true. otherwise, if their lengths are not equal, return false. otherwise iterate and compare [etc]". That would be closer to how it works in engines, and would involve one fewer kind-of-thing than we currently have (i.e. it would get rid of "sequence of code units"). If that was how the spec were written, strings would have identity from the perspective of the spec, but not from the perspective of ES code. _And that would be totally fine._ Symbol.for symbols are in the same situation. [18:38:05.0337] * Here is another analogy: the spec could, in principle, define strings as Lists of code units, and replace all existing uses of "is" on strings with SameValue, and change the SameValue algorithm for strings to be "if x is y, return true. otherwise, if their lengths are not equal, return false. otherwise iterate and compare \[etc\]". That would be closer to how it works in engines, and would involve one fewer kind-of-thing than we currently have (i.e. it would get rid of "sequence of code units"). If that was how the spec were written, strings would have identity from the perspective of the spec, but not from the perspective of ES code. _And that would be totally fine._ Symbol.for symbols are in the same situation. [18:39:28.0136] > "they have identity from the perspective of "is" and "contains", but do not have identity from the perspective of SameValue" First, SameValue does distinguish them, so I'm going to assume you're talking about being allowed as weakmap keys or not. Second, if that assumption is correct, wouldn't it be fine to just say that they are not suitable for use as a weak reference? [18:41:44.0194] bakkot: how is identity from the perspective of ecmascript code observed? [18:45:34.0901] (a tangent re strings as Lists of code units: you'd then have a language value that is also a spec value, which would involve some clarification.) [18:46:53.0155] `Object.is`, mainly [18:47:33.0610] it is also sufficient, but not necessary, to observe that changes to one reference thing to a thing affect other references to that thing, though this is only observable for mutable values [18:47:44.0804] * it is also sufficient, but not necessary, to observe that changes to one reference thing to a thing affect other references to that thing, though this is only observable for mutable values (obviously) [18:50:22.0095] then I think we should explore how we can talk about just the comparison operations and not introduce a second identity [18:51:16.0185] I do not think that [18:51:29.0804] I think we should distinguish between identity from the perspective of the spec and identity from the perspective of the language [18:52:21.0269] as a reader of the spec, it is useful to know which language values have identity from the perspective of the language, as well as it being necessary to understand which have identity from the perspective of the spec [18:52:37.0283] fortunately these differ in exactly one case, which is spelled out explicitly, at which point you know all there is to know [18:52:40.0254] this is the ideal situation [18:53:05.0214] I am feeling more lost now than ever [18:53:05.0759] talking about comparison operations would make this worse, because as a reader of the spec, the thing you care about is not the comparison operations, it's whether these things have identity from the perspective of the language [18:54:02.0452] SameValue distinguishes symbols (any symbols) based on their spec identity. How does that not expose the spec identity to the language? [18:54:40.0533] bakkot: You only care about that for comparison operations or mutable things! these are neither. [18:55:34.0042] I do not understand the question? [18:55:46.0249] I did not say anything about "exposing the spec identity to the language" at any point afaict [18:55:52.0743] * bakkot: You only care about that for comparison operations or mutable things! These are not mutable so it's only comparison operations we must care about. [18:56:22.0032] > fortunately these differ in exactly one case [18:56:25.0652] what case are we talking about? [18:56:33.0911] `Symbol.for` symbols [18:56:42.0877] what about them [18:57:00.0324] and the difference comes from the definition of identity: "may be manifest anywhere simply by fully describing their characteristics" [18:57:12.0880] _within the language_, `Symbol.for` symbols can be manifest by describing them [18:57:16.0316] _within the spec_, this is not true [18:58:26.0465] so within the language, Symbol.for symbols do not have identity; within the spec, they do [18:58:30.0372] * so within the language, Symbol.for symbols do not have identity; within the spec, they do [18:58:47.0170] when we say that about identity, we're not making it a derived characteristic based on that, we're just stating an implication [18:59:26.0969] "Values without identity are equal to other values without identity if all of their innate characteristics are the same" is literally where we `dfn` identity [18:59:40.0551] the only thing stopping you from manifesting a value anywhere is your inability to describe the indescribable identity [19:00:05.0157] yes but that thing is... the whole point? [19:00:09.0337] that's where we're defining equality (piecewise) [19:00:28.0817] ok? [19:00:36.0364] that does not contradict anything I said [19:00:43.0135] within the language, Symbol.for symbols can be manifest by describing them [19:00:45.0705] within the spec, this is not true [19:01:13.0761] so, by implication, it follows that within the language, Symbol.for symbols do not have identity, and within the spec, Symbol.for symbols have identity [19:03:49.0230] within the language, Symbol.for symbols can be retrieved using a subset of their characteristics that makes them unique among all Symbol.for symbols [19:03:58.0055] that is not the same as fully describing them [19:05:59.0660] as a reader of the spec, unless you are a philosopher, it is most useful to think of that as fully describing them. [19:06:39.0871] regardless, that is the property that Shu cares about for liveness and that is what we should say [19:06:51.0974] we should stop trying to relate this to spec identity [19:07:06.0163] we want a separate concept [19:07:44.0224] we should continue relating this to spec identity, because that is the precisely correct way to think about it in terms of motivation, semantics, and implications [19:08:11.0693] and Symbol.for symbols don't participate in liveness and so you don't need even need to think about the edge case [19:08:18.0602] * we should continue relating liveness to spec identity, because that is the precisely correct way to think about it in terms of motivation, semantics, and implications [19:09:10.0977] I am now more convinced than ever that the concept we want is precisely the one that I spell out in https://github.com/acutmore/ecma262/pull/3/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR12316 [19:10:16.0193] we want a concept that is defined in 3 parts, 1 part of which defers to (spec) identity; the other 2 parts are Symbol.for symbols and values without identity [19:10:50.0587] that note is fine for the "can be used as a weak reference" case, certainly [19:10:51.0032] call it whatever you like, but we should at least call it out explicitly [19:11:46.0725] what's the other case? [19:11:56.0572] maybe I just don't understand the other case then [19:12:04.0319] there's the definition of identity, and liveness [19:12:42.0297] the definition of liveness is touched in Shu's PR, and is good as it is in that PR; the symbols-as-weakmap-keys PR won't need to touch it [19:12:47.0739] * the definition of identity is touched in Shu's PR, and is good as it is in that PR; the symbols-as-weakmap-keys PR won't need to touch it [19:13:39.0603] and what does that accomplish? [19:13:49.0137] what does... what accomplish? [19:13:58.0152] > the definition of identity is touched in Shu's PR [19:14:29.0122] what does his PR accomplish? it corrects the definition of identity so that the edge case of Symbol.for symbols is explained [19:15:07.0086] the PR description says > to capture the reason for why Symbol.for symbols cannot be used as weak targets which you just agreed is already solved by my changes to CanBeHeldWeakly, so what else is it accomplishing? [19:15:49.0549] > it corrects the definition of identity so that the edge case of Symbol.for symbols is explained [19:16:08.0271] also I am assuming your note gets reworded to take that into account [19:17:02.0347] I don't know what literally anything at all means anymore [19:17:26.0876] there is no edge case of Symbol.for symbols for identity [19:17:32.0632] they have identity, period [19:18:35.0105] there's *another concept*, that we just discussed 2 minutes ago, that separates them out of that category for the specific purpose of "being a weak reference" [19:18:55.0982] why does anything else need to change? [19:18:56.0304] what is the other concept? [19:19:10.0769] "suitable for use as a weak reference" [19:19:24.0253] that concept _is_ the concept of having identity from the perspective of the language [19:19:42.0657] and the reason that those agree is because the relevant fact is "can be manifest without prior reference" [19:20:42.0143] like, the reason a thing is "not suitable for use as a weak reference" is because it "can be manifest without prior reference", i.e. _it does not have identity_ [19:20:59.0654] for immutable values, it is not observable from the language whether something has identity, only how it compares [19:21:53.0159] this is why you and Shu both keep saying "well Strings could have identity if we wanted them to" [19:21:58.0958] sure, but we *say* that they don't [19:22:04.0833] we also *say* that symbols do [19:22:21.0908] Strings could have identity _from the perspective of the spec_, not the language [19:22:31.0216] strings cannot have identity from the perspective of the language [19:22:36.0303] because they can be manifest without prior reference [19:22:41.0328] and it's not like we have real symbols and then virtual symbols once they enter the fictional world of the language, they're the *exact same values* [19:23:07.0691] "has identity" is _equivalent to_ "cannot be manifest without prior reference" [19:23:19.0217] bakkot: they very much could have identity from the perspective of the spec, as long as you don't have a comparison operation that allows you to observe it [19:23:29.0774] * bakkot: they very much could have identity from the perspective of the language, as long as you don't have a comparison operation that allows you to observe it [19:23:35.0171] no they could not [19:24:09.0261] for immutable values, you can only know that they *do* have identity (via a comparison operation that exposes this) or that they *may or may not* have identity (all other cases) [19:25:04.0631] unless you think that there's some kind of guarantee to the end user that SameValue (Object.is) is bottoming out in identity for certain values? [19:25:06.0661] but there's not [19:25:17.0356] the user has opaque black box comparison functions [19:26:15.0944] we would be doing a disservice to readers of the spec if we said "they may or may not have identity" [19:26:25.0040] 3 should not have identity [19:26:29.0804] strings should not have identity [19:26:35.0751] Symbol.for symbols should not have identity [19:26:40.0084] for exactly the same reasons in every case [19:27:01.0557] but Symbol.for symbols are symbols, whether we like it or not [19:27:07.0414] ... so? [19:27:20.0600] so when we create a symbol, it has identity [19:27:30.0280] no it doesn't [19:27:31.0730] when we place it in the GlobalSymbolRegistry, it cannot just lost identity [19:27:34.0474] it does within the spec [19:27:36.0940] it does not within the language [19:27:40.0952] that's what I'm talking about [19:27:59.0515] a spec value can't go from having an identity to not having an identity [19:28:13.0745] whether a thing has identity depends on your perspective [19:28:29.0267] and since we don't give the language fictional symbols, they must have identity too [19:28:31.0817] please see my earlier example of strings-as-List [19:29:07.0794] do you disagree with this claim: in the strings-as-List example, from the perspective of the spec, Strings have identity, but from the perspective of the language, they do not [19:29:38.0233] > for immutable values, it is not observable from the language whether something has identity, only how it compares > this is why you and Shu both keep saying "well Strings could have identity if we wanted them to" [19:30:14.0748] from the perspective of the language, it is unknowable [19:30:31.0950] > <@bakkot:matrix.org> I will un-stamp shu's PR for now but if we don't have something which satisfies everyone by EOD tomorrow I'm re-stamping so we can get 2777 landed that wfm [19:30:44.0709] michael, i implore you, please take a step back and consider the goal [19:30:51.0598] ok. I think it would be doing a disservice to readers of the spec to say that it is unknowable instead of saying that they do not have identity. [19:31:00.0034] * ok. I think it would be doing a disservice to readers of the spec to say that it is unknowable instead of saying that they do not have identity from the perspective of the language. [19:31:36.0173] I agree, and it's fine to say that [19:31:38.0645] in fact, we should [19:31:43.0695] ok [19:31:49.0362] strings do not have identity because we say so [19:32:03.0656] in the spec? [19:32:08.0743] but that means we can't call the spec things strings [19:32:10.0825] strings _within the spec_ do not have identity because we say so [19:32:18.0430] if we defined them as Lists, they would have identity within the spec [19:32:22.0782] precisely [19:32:36.0318] and doing so is in fact, an editorial change [19:32:39.0025] and, as you say, it is not knowable whether they have identity within the language [19:32:48.0334] but if we were in that world, would you seriously be arguing that we should say strings have identity without qualification, because it's not knowable within the language? [19:32:53.0587] my position is, that would do a disservice to readers. [19:32:56.0063] then we can't just pass these things in to the language [19:33:08.0304] and readers should be told that, in fact, they do not have identity within the language. [19:33:46.0519] > <@michaelficarra:matrix.org> then we can't just pass these things in to the language why can't we? [19:34:19.0832] the language values are not virtual, they are values in our spec universe just like any other [19:34:27.0571] values that all either have spec identity or do not [19:34:32.0742] that's correct [19:34:40.0087] in this world, strings have spec identity. [19:34:53.0712] in the strings as Lists world, they have spec identity, yes [19:35:15.0223] however, if we left it at that, we would do a disservice to readers, who should be told that, in fact, they do not have identity within the language [19:35:49.0924] bb in an hour, but again, michael, i implore you to take a step back and reconsider the goal of a specification [19:35:58.0217] of a programming language, that is [19:36:51.0215] is it not to be able to answer questions about how an engine behaves when given a program? [19:37:53.0125] to do that, we need to be able to say things like "if A is B, do this", but what "is" means is important [19:38:05.0716] we have not made the definition of "is" confusing [19:38:13.0266] every use of the word "is" within the specification is within the specification [19:38:22.0545] we have said which values have identity from the perspective of the specification [19:38:26.0731] there is absolutely zero ambiguity here [19:38:30.0656] symbols [19:38:49.0652] symbols have identity [19:39:08.0775] from the perspective of the specification, yes, that's true [19:39:16.0039] those same symbols which appear as reified values in the language [19:39:22.0175] that is also true [19:39:55.0442] I am waiting for you to say a thing which conflicts with Shu's PR [19:39:56.0674] there are other questions you can ask about the symbols, like "is this symbol eligible for use as a weak reference" [19:40:09.0505] again that is true [19:40:16.0197] and those answers can even change over time for the same symbol [19:40:32.0715] not for that particular question, no [19:41:04.0611] don't, given the language as is, sure [19:41:08.0525] but theoretically could [19:41:16.0422] should be allowed by the framework we're building, surely [19:41:24.0136] uh [19:41:28.0872] why [19:42:16.0999] like, it's true that if there were an entirely different conceptual model for weak references, things could be otherwise [19:42:40.0008] but the conceptual model we have is, things can be used as weak references if, and only if, they have identity from the perspective of the language; that attribute is stable over time [19:42:43.0904] I mean sure, whatever you like [19:46:13.0259] what value does "have identity from the perspective of the language" provide over "eligible for use in a weak map"? [19:47:17.0703] > in the strings as Lists world, they have spec identity, yes > however, if we left it at that, we would do a disservice to readers, who should be told that, in fact, they do not have identity within the language [19:47:53.0677] if you, a reader of the spec, encounter Symbol.for symbols, and think "oh those have identity" without qualification, you will have the wrong intuition about how the language works [19:48:30.0568] for example, you are likely to conclude that Symbol.for symbols are eligible for use in a weakmap, because the conceptual model is that things can be used as weak references if, and only if, they have identity from the perspective of the language [19:48:59.0486] so the spec should tell you this important fact about Symbol.for symbols when it is talking about identity [19:49:09.0275] "this important fact" being that they do not have identity from the perspective of the language [19:49:38.0272] in exactly the same way, and for exactly the same reasons, that in the strings-as-Lists world we would tell readers that strings do not have identity within the language [19:51:48.0644] a difference being that all things that are a certain kind of thing either do or do not have identity [19:52:20.0792] I don't know what that sentence means [19:52:28.0200] from the perspective of the spec, they have identity [19:52:32.0332] from the perspective of the language, they do not [19:53:52.0518] from the perspective of the spec, it is true that either all Xs have identity or all Xs do not have identity, for any type X [19:54:38.0511] ok, so Symbol.for symbols have identity from the perspective of the spec, great [19:54:46.0989] but they do not have identity from the perspective of the language [19:54:57.0229] that is compatible with what you said [19:55:03.0388] and is an important fact readers should be told [19:55:05.0826] this is what shu's PR does [20:01:38.0426] i have another angle to offer up that michael might find helpful: first, let's agree that identity means "manifestability without prior reference for the purposes of equality comparison" the goal of the spec is to precisely describe JavaScript's behavior. whether values in JS can be manifested without prior reference and compare equal via `===` and `Object.is` is the actual important design choice. strings in JS don't have identity, Symbol.for symbols don't, Objects do, etc. in this framing, the spec is viewed as an implementation, and it can choose to implement the comparison behavior wrt identity or identity-less values [20:03:44.0019] in this spec-viewed-as-implementation, it's also important to understand the semantics of the implementation language. in a real implementation in C++, we must understand C++. our specification dialect of English, we need to also define how to do comparison for the spec values (the implementation data structures) [20:04:02.0874] what work is "for the purposes of equality comparison" doing there? [20:04:08.0116] I don't get that [20:04:21.0493] sorry, let me finish first [20:04:28.0186] then i'll address that [20:06:23.0279] because this is not a real implementation that needs to be executable, strings were specified "metacircularly" as these objects that directly have all the characteristics JS strings already have, and so they can be directly used across both the meta-spec layer and the surface language layer. in a C++ implementation this won't work because we don't have a string that conveniently already behaves exactly as we need to [20:07:42.0679] my point here is that that choice is a convenient "implementation detail". the important thing is actually *not* specification identity, but language identity. specification identity is the implementation detail, and is a separate thing [20:08:13.0117] i feel you're getting hangups by treating specification identity as the thing that should be "driving up" [20:09:15.0989] yeah, probably, but that's our medium, what else could we do? [20:10:18.0059] > <@michaelficarra:matrix.org> what work is "for the purposes of equality comparison" doing there? the work that's doing is that identity, as used by programmers, is shorthand for "is it only equal to itself when using `==`" [20:10:41.0506] honestly I think the only thing we're disagreeing on at this point (maybe all we ever were) is whether we actually name the "language identity" concept and what we call it [20:10:54.0214] and maybe whether or not we can get away with just talking about comparisons and never even introducing it [20:11:14.0738] > <@michaelficarra:matrix.org> yeah, probably, but that's our medium, what else could we do? what i propose we could do is recognize that for convenience's sake, because we are an english spec and not a executable implementation, all language values *could* be conveniently metacircularly defined as these things that happen to have all the properties we need already [20:11:26.0055] where we messed up, inadvertently, is the introduction of Symbol.for symbols [20:12:23.0878] and i propose, that instead of being overly formal by explicitly defining 2 identities, we use "identity" without further qualification and use "from the perspective of" [20:12:29.0919] and recognize that it is in fact not contradictory [20:12:52.0359] * and i propose, that instead of being overly formal by explicitly defining 2 identities, we use "identity" without further formal qualification and use "from the perspective of" [20:13:51.0330] and because spec identity is just an implementation detail [20:14:55.0527] And is it insufficient to only add "suitable for use as a weak reference"? Like why do we need to bring in all the baggage of identity by tying it to spec identity so closely? [20:15:11.0720] i don't follow [20:15:19.0816] i don't follow the second question [20:15:33.0344] and it is insufficient, in a disservice-to-the-reader way [20:15:52.0642] because identity is the concept that ties together our maintaining the design choice we already made for weak things: no primitives [20:16:00.0404] it's not because they aren't primitives, it's because they don't have identity [20:16:05.0155] * it's not because they are primitives, it's because they don't have identity [20:16:10.0571] I'm still not understanding what problem remains unsolved by just merging https://github.com/acutmore/ecma262/pull/3 [20:16:38.0447] i feel like both kevin and i have both repeatedly said "disservice to the reader" [20:16:46.0737] i think it is important to get across the design rationale being identity [20:16:52.0981] identity and weakness are closely tied [20:17:09.0834] well the "suitable for use as a weak reference" splits the universe of values into 3: values with identity (except Symbol.for symbols), Symbol.for symbols, and values without identity [20:17:26.0974] i find that to be a disservice to the reader [20:18:00.0533] why does weakness have to be tied to a concept that we call identity? [20:18:05.0587] we can disagree on that particular value judgment, but given that it's 2-to-1 and we've discussed this at length... [20:18:08.0804] why can't it be tied to this other similar concept? [20:18:30.0246] because the connection is well understood in PLs and compilers and VMs [20:18:49.0892] but this PL is bad and has separated it in design [20:19:04.0768] it hasn't, Symbol.for doesn't have identity [20:19:23.0549] it's "bad" in the sense that its type system doesn't align on identity or identity-less boundaries [20:19:41.0231] * it hasn't separated, Symbol.for doesn't have identity [20:20:07.0778] you have stipulated that it is inviolate that all values of a language type must have or not have identity [20:20:13.0366] that is, however, not a fact of the world [20:20:13.0762] well *additionally*, the way the language is spec'd, many meta-level concepts are exposed directly at the fiction level [20:20:30.0824] exposed directly at the language level you mean? [20:20:33.0661] meta-level is the fiction level [20:20:53.0072] lol I guess it depends on perspective [20:21:01.0790] not in this case [20:21:08.0358] the spec defines "spec type" as a thing [20:21:17.0968] that we learned earlier today that you did not agree with [20:21:19.0947] to the spec, all spec things are real and the language is a virtual thing [20:21:40.0620] i'm sorry michael i'm not going to go on a tangent to dive into "real" [20:21:48.0867] I was just not aware that it excluded language values, I thought it was defined to be superset relationship [20:22:00.0491] i think that is more signal that your mental model is in fact not the spec's [20:22:02.0760] nor mine and kevin's [20:22:19.0789] and given that i think you actually understand our view at this point [20:22:26.0668] i'd like to move forward with my PR [20:23:05.0969] (conversely i think we also understand yours) [20:24:41.0346] corollary to all this is that i think the root reason you're getting hung up is that you want to optimize for rigor in the language of the spec itself, which i think kevin and i also disagree with you on [20:24:47.0887] I think defining and naming "spec identity" and "language identity" makes everyone happy, but one or both of you just didn't like the aesthetics of it [20:25:25.0423] sure, let's draw out the matrix [20:25:48.0433] I don't think I optimise for rigour, I just think identity, of all places, is a place that really needs it [20:26:24.0846] - i prefer my current PR. i can live with "spec identity" and "language identity", but think it is non-ideal for complexity reasons Kevin has raised. - you disprefer my current PR. you can live with "spec identity" and "language identity" - kevin prefers my current PR. it is unclear if he can live with "spec identity" and "language identity" [20:26:28.0369] I mean, before we added the identity section, we actually experienced cases of ambiguity arising from it [20:26:42.0494] sorry, not rigot, i misspoke, i actually meant formality [20:26:46.0570] formality of the surface language [20:26:54.0433] i still contend the rigor of the 2-identity model exists in my current PR [20:27:07.0041] so my concrete proposal is: if kevin can live with "spec identity" and "language identity", let's revert back to that state [20:27:08.0709] > makes everyone happy it does not make me happy; it's more than the current PR [20:27:12.0195] * > makes everyone happy it does not make me happy; it's more than the current PR [20:27:26.0231] if he cannot, let's go with my current PR, and you should consider yourself overruled michael, under protest [20:27:26.0472] * > makes everyone happy it does not make me happy; it's more confusing than the current PR [20:28:01.0619] specifically I really do not want to have a table [20:28:04.0869] is that reasonable to everyone as the playbook to get an actionable conclusion? [20:28:15.0407] oh i can remove that table and use prose [20:28:18.0642] bakkot: we could do away with the table [20:28:22.0620] and just have a special sentence for Symbol.for [20:28:27.0882] that's what we currently have [20:28:32.0942] I also had prose suggestions if we were going that route [20:28:40.0795] we don't currently have s for spec and language identity [20:28:43.0668] currently meaning in your PR [20:28:48.0282] i think michael is saying let's bring back s for it [20:28:48.0705] I just didn't bother leaving them until I kenw which way we were going [20:29:14.0362] I definitely do not want those terms dfn'd or used anywhere outside of the section on identity [20:29:23.0593] I can live with using those terms, but not dfn'ing them, within the section [20:29:33.0666] though that seems worse than what we have in the PR [20:29:48.0771] I think I understand that the thing you're saying with "they have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language" is actually just another way of phrasing the spec/language identity differences [20:29:55.0617] yes [20:30:00.0803] but I would rather be more clear that these are two concepts [20:30:11.0879] not one conditional concept, which is how I fear it would be read [20:30:18.0697] okay here's how we can thread the needle [20:31:12.0996] - define the formal concepts with s in the identity section - don't use the 'd terms, just "identity", elsewhere in the spec, because as we've discussed, Symbol.for values don't figure into the other places so it doesn't matter - use "language identity" in the NOTE in CanBeWeakTarget, because that's precisely where i want to surface the concept [20:31:43.0388] yeah that sounds like it would be good [20:32:29.0919] I can live with that [20:32:47.0947] excellent [20:32:50.0039] i will do that tomorrow [20:32:52.0092] i am tired noq [20:32:56.0545] * i am tired now [20:32:59.0336] like I said last week, it feels to me like it introduces more than is necessary to satisfy the problem, but I have no problem with it [20:33:28.0393] k I gotta go too [20:34:19.0657] talk tomorrow [09:45:49.0465] will `language identity` still be dfn'd? [10:32:28.0078] no [10:32:30.0625] just 'd [10:55:01.0746] :-/ that's unfortuante [10:55:03.0945] * :-/ that's unfortunate [13:34:01.0144] new commit up, PTAL bakkot Michael Ficarra : https://github.com/tc39/ecma262/pull/3027 [14:01:24.0306] I would probably swap the order of the Symbol.for part, but otherwise LGTM [14:05:00.0231] > Symbol produced by Symbol.for do not have language identity. All other Symbols have language identity. [14:06:06.0554] can you share your updates to CanBeHeldWeakly? [14:19:27.0454] my git fu is not strong enough [14:19:32.0837] how do i get a clean PR against acutmore's branch [14:19:40.0631] (how did you do it?) [14:22:18.0206] You mean you already have the commit, it's just the creation of the PR that you're asking about? [14:24:40.0166] i'm asking specifically about #2777 [14:24:56.0239] it has merges in it, and i don't know how to rebase it on my PR and create a clean PR against #2777's upstream branch in acutmore's repo [14:25:12.0209] i can like... squash everything and push to a new branch [14:26:48.0147] Rather than rebase it on your work, you wouldn't rebase your work on it? [14:26:59.0940] oh uhhh [14:27:02.0173] i don't know [14:27:07.0623] why would i do that? logically my PR should land first [14:28:35.0991] your PR against 2777's upstream branch should land in that branch before what? [14:36:33.0242] someone needs to write a "Git for Engineering Directors" book [14:37:53.0059] (I don't understand what you mean by "land first". first before what?) [14:38:19.0847] at a high level, the timeline of what i think should happen: - my PR lands - #2777 rebases on top of my PR, and lands what i am trying to do: how do i open a PR (call it PR2777) against the branch on which #2777 is created from so that, once my PR lands, we land PR2777 against 2777's upstream (acutmore's), then land #2777 [14:38:57.0588] ah [14:40:27.0008] Is the point of PR2777 just to accomplish the rebasing of #2777 on your first PR? [14:41:26.0733] the point of PR2777 is 1) to show michael updates to CanBeHeldWeakly, because that's defined in there and 2) land #2777 ASAP with a few button presses after my PR lands [14:43:14.0830] so you want to accomplish the rebasing of 2777 before your first PR actually lands? [14:43:34.0909] that is correct [14:44:31.0744] Michael Ficarra: swapped [14:45:59.0472] And the merges in 2777 are complicating the desired rebase? [14:48:43.0653] also correct [14:49:37.0062] then I think my git fu is also not strong enough, sorry [14:52:15.0614] So when the rebase gets to a merge-point, you can't just treat it the same as a rebase conflict? [14:52:24.0644] I'm sure that I have the requisite git skill, but I don't understand what you're trying to do [14:53:09.0234] i might be holding it wrong in my mind [14:53:22.0186] let me just push to my own repo and show you the wording Michael Ficarra [14:53:27.0233] we can figure out the git surgery later [14:53:28.0422] lol k [14:56:56.0867] https://github.com/syg/ecma262/commit/f28058faabad41a4c4a65597cf5927e2e83e3e91 [15:05:42.0869] can you use "suitable for use as a weak reference" or "unsuitable for use as a weak reference" as if it were a defined term? [15:05:50.0931] I'd like to be consistent with that phrasine [15:05:56.0060] * I'd like to be consistent with that phrasing [15:07:55.0327] also pull in my grammar fixes in the last sentence: > However, any value associated to a well-known symbol in a live WeakMap is unlikely to be collected and could "leak" memory resources in some implementations. [15:35:51.0949] > <@michaelficarra:matrix.org> can you use "suitable for use as a weak reference" or "unsuitable for use as a weak reference" as if it were a defined term? you mean always spell it out? [15:36:20.0313] ...why? do you think it's ambiguous currently? [15:37:11.0714] wfm to always spell it out for 2 sentences [15:37:22.0832] if there were more sentences i don't think i'd want to repeatedly read that phrase over and over [15:37:28.0637] no, it's not ambiguous, I just prefer it to be used more like a defined term, even if we don't care to dfn it [15:40:16.0503] > <@michaelficarra:matrix.org> also pull in my grammar fixes in the last sentence: > > > However, any value associated to a well-known symbol in a live WeakMap is unlikely to be collected and could "leak" memory resources in some implementations. WDYT about just "in implementations" [15:40:19.0794] avoid any additional qualifiers [15:40:47.0981] sounds good [15:44:25.0644] https://github.com/syg/ecma262/commit/7511eeba7ae2c6ab5e5314bef912d8ac0d9b15c8 [15:47:06.0178] with that, do we think https://github.com/tc39/ecma262/pull/3027 is ready to merge? [15:48:04.0235] if so i think the git surgery that is easiest would be to merge that, merge main back into acutmore/symbols-as-weakmap-keys, and then apply michael's PR with my modifications against acutmore/symbols-as-weakmap-keys [15:48:39.0680] yeah I think so [16:21:12.0269] ljharb: what's that force push in https://github.com/tc39/ecma262/pull/3027? [16:21:58.0186] oh kevin has a comment [16:24:52.0815] two comments [16:24:59.0455] lgtm otherwise [16:25:40.0668] also do want to register that this is, IMO, significantly worse than the previous PR which talked about "identity from the perspective of" [16:26:00.0580] but I will suck it up so we can land it [16:26:56.0163] well the perspective language is still there in the identity section [16:27:00.0170] just not in the CanBeHeldWeakly note [16:27:06.0890] and... we just don't use it anywhere else [16:27:08.0512] and that seems ok [16:27:22.0736] sorry I mean specifically introducing "language identity" and "spec identity" as terms [16:27:24.0307] is bad [16:27:27.0989] I really quite dislike doing thta [16:27:30.0836] * I really quite dislike doing that [16:27:37.0487] that force push was me getting ready to merge it [16:27:41.0577] again, not suggesting to change it [16:27:44.0811] just registering displeasure [16:29:55.0916] yeah i mean, yeah [16:30:08.0833] ljharb: ah okay let me apply kevin's last comment and we should be gtg [16:33:26.0653] bakkot: all right, see if the reworded paragraph wfy [16:34:58.0214] lgtm [16:35:35.0144] okay, i gotta run but will do 2777 tomorrow morning probably [16:35:38.0033] should be easy 2023-03-17 [17:01:57.0959] https://fenix.tecnico.ulisboa.pt/downloadFile/1689244997263330/ECMA_SL_Extended_Abstract.pdf is interesting: "Hence, we believe that the ECMAScript specification should be generated from a reference implementation of the language." [17:05:55.0887] Mind you, they're (apparently) writing in 2021 about ES 5.1, which is odd. [17:30:07.0166] my undergrad research back in ~2014 was against ES3 [17:30:11.0869] it's just a lot easier to use old versions [17:30:14.0536] new versions are... larger [17:34:26.0655] as an editor, I would prefer to maintain spec text and derive reference implementations for the purposes of automatically checking the spec, not the other way around [18:54:25.0214] Given that people will read the text, it does seem that maintaining the text and deriving an implementation is safer than the reverse. With the reverse, you'd presumably have to generate the text as part of CI, and then diff that against the previous text, so more stuff to check. [19:14:35.0718] And if you can derive a reference impl from the text, then you get benefits 2-4 anyway. Benefit 1 ("Writing code is easier than writing HTML pseudo-code following the conventions of the standard.") is a weird thing to say because ES 5.1 was written in MS Word. In the current regime, I'm not sure which would be easier. Writing code might be more satisfying, because you could (at least sometimes) get into a quick feedback loop. [08:47:41.0316] well also, like, our spec isn't 100% executable [08:47:47.0227] re: liveness and memory model [11:34:50.0991] git question time, how do i cherry-pick the commit from a PR into my local branch? [11:37:37.0741] `git cherry-pick X` where X is any commit-ish [11:37:44.0546] the short or long sha, eg [11:37:55.0199] no i mean [11:38:02.0211] how do i find that sha [11:38:25.0010] like what repo and branch i need to fetch to get that sha [11:40:50.0653] oh - you can get it from the PR webpage most easily [11:41:08.0272] ah okay [11:41:12.0875] to get it on the CLI you have to fetch the PR ref specifically, which i'd need a minute to craft the command for [11:41:28.0817] ah no need, i'll try to find it on web page [11:41:31.0436] cool [11:47:02.0054] thanks [11:47:24.0153] bakkot Michael Ficarra i've cherry-picked michael's commit and added my wording tweaks on top to https://github.com/tc39/ecma262/pull/2777 [11:47:26.0824] PTAL [11:47:38.0230] it should be the agreed-upon state [12:46:27.0055] > <@jmdyck:matrix.org> And if you can derive a reference impl from the text, then you get benefits 2-4 anyway. Benefit 1 ("Writing code is easier than writing HTML pseudo-code following the conventions of the standard.") is a weird thing to say because ES 5.1 was written in MS Word. In the current regime, I'm not sure which would be easier. Writing code might be more satisfying, because you could (at least sometimes) get into a quick feedback loop. i think a consequence of writing non-executable specifications _first_, while appearing inefficient and annoying on paper, is good in practice for JS, actually, because of the highly interoperable nature of JS [12:47:35.0932] i can guarantee you what will happen with a reference interpreter as the source of truth is that, implementations will more than likely converge on whatever the reference implementation does for new proposals, down to bug compat [12:48:05.0370] because our spec drafts aren't executable, there's more doubt cast on the correctness of it by implementers when something doesn't smell right [12:48:42.0576] vs what i contend will happen in a reference-implementation-first world, which is "well this sure seems like a weird design but the reference implementation already does this so it must be intentional, i'll just copy that" [12:49:27.0500] and because we have multiple interoperable implementations, there're more chances for doubt to be cast, which i feel like raises the quality bar [12:49:37.0551] at the expense of small set of people being annoyed, of course, but that seems fine [12:49:59.0954] i think that's how ruby's tended to work [12:50:09.0571] * i think that's how ruby's tended to work (as shu described, i mean) [12:50:47.0478] python too [12:50:49.0364] oh yeah? there're multiple ruby implementations? i didn't know [12:50:56.0812] i know for python there's the JIT forks [12:51:02.0422] like pypy and whatnot [13:01:39.0841] yeah, at least back in the day jruby was a big deal [13:01:46.0084] but the reference implementation was in c [13:01:52.0474] * but the reference implementation was in C [13:02:02.0336] * yeah, at least back in the day jruby (a JVM impl) was a big deal [13:08:42.0734] Michael Ficarra: for https://github.com/tc39/ecma262/pull/2777#pullrequestreview-1346560131 do you prefer the singular everywhere? [13:22:02.0781] I'm not an expert in English grammar, but to me "use as" is always followed by a singular form [13:22:40.0255] but like I don't know if that's an actual English grammar rule or if that just sounds natural to me because I've heard it used incorrectly? [13:22:41.0831] I dunno [13:23:16.0798] it's like "these tools are not suitable for use as a hammer", which sounds better to me than if it was pluralised [13:24:29.0905] "these tools are not suitable for use as hammers" is also perfectly correct afaict [13:24:59.0120] > <@michaelficarra:matrix.org> it's like "these tools are not suitable for use as a hammer", which sounds better to me than if it was pluralised that sounds like, 2x worse to me than the pluralized version [13:25:47.0765] i don't know if there's a rule here either [13:26:05.0463] I read it as "use as a hammer" is the thing they're unsuitable for [13:26:17.0493] and "use as hammers" is not a thing [13:26:55.0002] anyway, it's not a big deal, the thing I was really trying to get at was consistency in phrasing [13:27:01.0094] as long as it's the same everywhere, it's fine [13:27:56.0233] i think then i will make everything singular [13:28:02.0891] that sounds better than mixed and avoids the question [13:28:16.0204] i.e. "a value" instead of "values" [13:35:49.0991] "value" still needs to correspond to "is" though [13:35:57.0662] in that last sentence [13:36:27.0142] and we still need to drop the curly quotes because eww [13:38:54.0678] yeah sure, i'll apply the rest of your suggestions [14:54:37.0589] psh, only curly quotes are typographically correct in prose [14:57:20.0753] ,,x'' 2023-03-18 [21:10:04.0580] shall I stamp it as ready then? [21:40:38.0528] shipit [21:44:15.0152] stamped [21:50:30.0165] sigh, it uses a merge commit and so it conflicts with the identity stuff [21:51:14.0565] rebasing [22:00:56.0836] landed. (i'd still like to see 2974 get in before the cut, if possible) 2023-03-19 [19:46:09.0878] is that just waiting on a review from shu? [22:10:51.0411] yep, i believe so 2023-03-20 [08:28:27.0846] thanks for ping, i'll review it today [12:53:07.0104] other than 2974 are we all green on 2023 cut? [12:56:03.0633] I believe so [14:54:19.0073] I closed the Editors request for feedback today. The results are a 100% approval rating and one text comment: >Contributing to Ecma262, I've found it difficult to ensure my work conforms to the latest conventions requested by the editors. This can hold up contributions for months in consecutive rounds of review. I'd request that the editors work on documenting the necessary writing style and conventions in a style guide for contributors. If a contribution in progress raises a new question about some phrasing consistency, I'd prefer the editors to err on the side of settling the consistency question later so as not to hold up the contribution. [15:15:58.0869] I agree that it's difficult (before review) to ensure conformance to editorial conventions, and that a style guide would help. However, I'm doubtful that it's "held up contributions for months in consecutive rounds of review". Hold-ups and rounds of review *do* happen, but I don't think editorial conventions are the cause. Maybe I'm forgetting some cases though. [15:18:31.0534] i take that as a signal that they'd like either quicker turnaround, or to for editors to take over for smaller changes instead of asking for multiple rounds of back-and-forths [15:19:10.0359] and given the unpredictability of available time each of us has from week-to-week, i lean towards the latter solution [15:19:40.0330] or at least open that up as a request by the PR author, that they can ask us to take something over [15:19:57.0476] * i take that as a signal that they'd like either quicker turnaround, or for editors to take over for smaller changes instead of asking for multiple rounds of back-and-forths [15:26:20.0592] yes, we talked about this feedback at an editor call and decided to take over PRs when they only need minor editorial changes to land [15:33:02.0736] (unless the submitter explicitly requests otherwise; jmdyck I think you've said you'd prefer to manage those things for yourself) [16:29:08.0015] I'll always want to take my PRs to merge-ready, yes. [16:30:51.0636] (modulo a squash, I suppose) 2023-03-21 [10:20:44.0222] so is https://github.com/tc39/ecma262/pull/2974 ready to land? [10:22:42.0157] i see 3 stamps, my last comments were addressed, so seems like it to me [10:25:01.0102] added the label [12:59:26.0260] Is https://github.com/tc39/ecma262/projects/1#card-43826692 ("more widespread use of abstract closures") still "to do"? [13:00:17.0106] (Maybe https://github.com/tc39/ecma262/pull/2439 finished it.) [13:02:32.0841] well well gonna have to start referring to you as MR GIBBONS and MR FICARRA [13:22:01.0105] lol Joel is very formal [13:22:11.0558] he works with a lot of people with Cs in their titles 2023-03-27 [10:41:33.0017] ljharb: have you happened to tag es2023 yet? [10:44:25.0721] i have not [10:45:14.0900] lmk when yall think it's ready tho and i can [10:45:35.0681] my understanding is it was ready at the start of plenary last week [10:45:49.0505] bakkot Michael Ficarra to also confirm? [10:46:24.0647] yeah I didn't think we were planning on anything else [10:46:31.0549] :shipit: [10:46:40.0509] cool, i'll cut it this week 2023-03-30 [18:33:14.0719] ljharb: we added the intro section in https://github.com/tc39/ecma262/pull/3032, so I think all that remains for the cut is the metadata update to say it's not a draft [18:33:37.0410] let us know when you've made the cut so we can distribute the new permalink URL to those who have asked for it 2023-03-31 [17:14:43.0734] bakkot: i pushed up the `es2023` branch, but neither of https://tc39.es/ecma262/2023/ nor https://tc39.es/ecma262/es2023/ are loading (https://tc39.es/ecma262/2022/, 2021, etc load). any tips? [17:56:53.0020] Needs to be built and committed to the branch manually; it doesn't build every commit since it's supposed to never change [17:57:06.0753] I can get to it... uh, probably tomorrow, looking at the rest of my day, if you don't get to it before then [17:57:17.0830] * Needs to be built and committed to the gh-pages branch manually; it doesn't build every commit since it's supposed to never change [18:38:09.0909] ah ok. No rush at all [18:38:50.0948] I’m driving back from Tahoe tomorrow so I’ll check on it after that