| 00:00 | <bakkot> | I gotta run off for the next ~30m |
| 00:00 | <Michael Ficarra> | 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."? |
| 00:00 | <bakkot> | that wfm |
| 00:00 | <bakkot> | maybe |
| 00:00 | <shu> | i don't like "as if" |
| 00:00 | <bakkot> | will think about it when I get back |
| 00:01 | <shu> | they literally do not have identity |
| 00:01 | <shu> | 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. |
| 00:02 | <Michael Ficarra> | they are values with identity but the strategy used for comparing them does not observe the identity, it follows the other path |
| 00:02 | <shu> | i disagree |
| 00:02 | <Michael Ficarra> | we could say something like "their identity does not participate in the comparison" or something |
| 00:02 | <shu> | i think if we say that, we should go back to actually defining the stratified identities |
| 00:03 | <shu> | 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 |
| 00:03 | <shu> | there is no "as if" |
| 00:03 | <shu> | we defined values to have identity or not have it wrt a particular comparison operation |
| 00:03 | <shu> | at the language level, they do not have identity |
| 00:03 | <Michael Ficarra> | 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? |
| 00:04 | <shu> | okay, then we can say "(with the following exception)" in the previous sentence |
| 00:04 | <Michael Ficarra> |
I don't interpret it that way |
| 00:05 | <shu> | i do? |
| 00:05 | <shu> | dunno what to tell you, this is the start of our disagreement |
| 00:05 | <shu> | and we seem to have lost the agreement that there are in fact 2 identities |
| 00:05 | <Michael Ficarra> | can you point to where it says that? |
| 00:06 | <shu> | i say: "When comparing for equality, values fall into one of two categories." |
| 00:06 | <shu> | formally, i mean: values are categorized as having or not having identity, parameterized by the equality operation |
| 00:06 | <shu> | i.e. "when comparing for equality" |
| 00:07 | <shu> | there are two levels of "when comparing for equality". at the spec level, with "is" and "contains", and at the language level, with SameValue |
| 00:07 | <shu> | it so happens this distinction is not useful at all almost all the time, except the few places we talk about Symbol.for |
| 00:08 | <shu> | so i agree it's confusing to actually <dfn> two concepts, and instead just add a paragraph that calls out the one place where it differs |
| 00:08 | <Michael Ficarra> | 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 |
| 00:09 | <shu> | that is not my intention, and that is why i split the paragraphs up the way i did |
| 00:09 | <shu> | let's see... 1) do you agree my reading is fine and 2) any suggestions on how to make that reading clearer? |
| 00:12 | <Michael Ficarra> | 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. |
| 00:12 | <Michael Ficarra> | that's why we settled on the two identities approach being acceptable, even if undesirable because of potential naming confusion |
| 00:12 | <shu> | you have a permanent and intrinsic property at each level that do not interfere with each other |
| 00:13 | <shu> | moreover, how that property is defined is exactly the same across both levels |
| 00:13 | <Michael Ficarra> | it's not intrinsic if it depends on the lens through which you're currently looking at it |
| 00:13 | <shu> | i think what you are saying is you desire for "identity" to be entirely axiomatic |
| 00:13 | <shu> | it is intrinsic |
| 00:14 | <shu> | i'm sorry i don't understand your hangup here |
| 00:14 | <shu> | 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 |
| 00:15 | <shu> | like, the spec necessarily works in 2 layers: the meta spec layer, and the language layer |
| 00:15 | <shu> | that doesn't make the language layer less intrinsic |
| 00:16 | <Michael Ficarra> | 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. |
| 00:17 | <shu> | i say that is a ill-formed question to ask |
| 00:17 | <shu> | there is no singular identity to ask of an ECMAScript language value, there are necessarily two questions |
| 00:18 | <Michael Ficarra> | now we're talking about the identity of the concept of identity |
| 00:18 | <shu> | does it have an identity in the spec meta-machinery and an identity in the language |
| 00:18 | <shu> | no we're not |
| 00:18 | <Michael Ficarra> | there literally is one true identity |
| 00:18 | <shu> | concretely, consider a real implementation |
| 00:18 | <shu> | i do not ask "do strings have identity" |
| 00:18 | <shu> | i ask "does the C++ implementation of JS strings have identity? (yes, they are heap objects)" |
| 00:18 | <shu> | or i ask "do JS strings have identity?" (no they don't) |
| 00:18 | <shu> | i do not ask "what is the one true identity-ness of strings" |
| 00:18 | <shu> | that question doesn't make sense |
| 00:19 | <Michael Ficarra> | yes but we are living in the world of spec text, so identity must mean spec identity |
| 00:19 | <shu> | okay, then you would in fact prefer that we do define "language identity" as a separate thing |
| 00:19 | <shu> | which i feel is important to define for the liveness definition |
| 00:19 | <shu> | and not just use "from the perspective of" language |
| 00:20 | <Michael Ficarra> | 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 |
| 00:20 | <shu> |
we aren't, just like in a C++ implementation we don't just care about the identity of the C++ structures |
| 00:20 | <shu> | it's a spec text that specifies a language |
| 00:20 | <shu> | a surface language |
| 00:21 | <shu> | like i don't know how you think about language specifications if you think concepts should pierce the meta-language and surface-language layer |
| 00:21 | <shu> | that seems untenable |
| 00:21 | <Michael Ficarra> | no, I think all concepts are meta-language concepts |
| 00:21 | <Michael Ficarra> | and surface concepts aren't directly discussed, they just arise from meta-language |
| 00:22 | <Michael Ficarra> | like ECMAScript language values are values within our spec universe |
| 00:22 | <Michael Ficarra> | they're just also 1-to-1 with values that are observed within our fiction |
| 00:22 | <shu> | 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! |
| 00:22 | <Michael Ficarra> | of course, you're correct |
| 00:23 | <Michael Ficarra> | they can have close names, it's just a bit unfortunate, that's all |
| 00:23 | <shu> | like it's really really hard to not name them when talking about properties like liveness |
| 00:23 | <Michael Ficarra> | 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) |
| 00:23 | <shu> | to the point where we do our readers (well, our implementers) a huge disservice |
| 00:23 | <shu> | because they are thinking about what optimizations and GCs are allowed |
| 00:24 | <Michael Ficarra> | 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 |
| 00:24 | <shu> | because it made me realize the liveness definition is wrong |
| 00:25 | <shu> | or at least, very misleading to me |
| 00:25 | <shu> | even if incidentally correct because the domain happens to have been restricted |
| 00:25 | <Michael Ficarra> | but can't the definition refer to that pair? |
| 00:26 | <shu> | 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 |
| 00:26 | <shu> | and we cannot convince each other |
| 00:26 | <shu> | (for why i'm not okay with the pair) |
| 00:28 | <bakkot> | I very strongly vote for keeping shu's PR as-is, no matter how unsatisfying michael finds it |
| 00:28 | <shu> |
this seems to be the crux of it. i most definitely do not think that, nor does the spec as it's been written |
| 00:28 | <bakkot> | 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 |
| 00:29 | <shu> | fair, wfm of course, i want to get back to rebasing 2777 |
| 00:29 | <Michael Ficarra> | bakkot: did you read the conversation? I think we've resolved it in the same way we resolved it last time. |
| 00:29 | <bakkot> | (though I'm fine with adding the "with the following exception" bit) |
| 00:29 | <shu> | Michael Ficarra: but kevin also didn't like the extra <dfn>s |
| 00:29 | <bakkot> | Michael Ficarra: I did read it and it did not seem resolved? |
| 00:29 | <bakkot> | yeah I really do not want to define two notions of identity here |
| 00:29 | <shu> | and i tend to agree, it doesn't really help readability |
| 00:29 | <bakkot> | I want exactly the thing in the PR |
| 00:31 | <Michael Ficarra> | I can't accept something that defines values with conditional identity. The equality operation can be conditional, but identity must be innate and immutable. |
| 00:31 | <bakkot> | I think at some point we are going to have to say too bad and land something |
| 00:31 | <shu> | michael it is not conditional |
| 00:31 | <shu> | yeah i think i'm doing arguing this, let me add the (with the following exception) |
| 00:31 | <Michael Ficarra> | identity that depends on the lens through which you are looking at it is conditional in my book |
| 00:32 | <shu> | then you should correct your thinking :) |
| 00:34 | <Michael Ficarra> | 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? |
| 00:34 | <shu> | my brother in christ i work with compiler writers, not philosophers |
| 00:34 | <bakkot> | yes, this document is not for philosophers |
| 00:35 | <bakkot> | 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 |
| 00:35 | <Michael Ficarra> | yes, but they can teach us some things about building formal logical systems |
| 00:35 | <shu> | michael |
| 00:35 | <bakkot> | only if we use language in a way that will be coherent to the people who we are addressing |
| 00:35 | <shu> | i also regret to inform you you work on javascript |
| 00:35 | <bakkot> | which is not philosophers |
| 00:35 | <shu> | not the lambda calculus cube |
| 00:40 | <shu> | okay i applied all other comments except the last sentence one, so should be gtg. let me continue with rebasing 2777 now |
| 00:42 | <Michael Ficarra> | 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 |
| 00:43 | <shu> | i think we are very rigorous here |
| 00:43 | <shu> | the actual rigor is there are 2 identities |
| 00:43 | <shu> | we find it editorially confusing to surface that foundation with 2 different dfns |
| 00:44 | <shu> | so we use one word, identity, because in all cases the truth tables they produce are the same |
| 00:44 | <shu> | where the truth tables differ, we use a sentence |
| 00:45 | <Michael Ficarra> | then why do we have to use identity in that sentence? |
| 00:45 | <shu> | which sentence? |
| 00:46 | <Michael Ficarra> | is it not the final sentence of the identity section that you were talking about? |
| 00:46 | <shu> | are you asking why an english sentence can be ambiguous without context, but also disambiguated with a following sentence? |
| 00:47 | <Michael Ficarra> | If you're talking about the final two sentences of the identity section, there is nothing ambiguous, there is just a contradiction. |
| 00:47 | <shu> | okay, i see i am not getting through |
| 00:47 | <shu> | protest noted |
| 00:47 | <shu> | i think you're overruled michael, sorry |
| 00:48 | <shu> | i would like to finish this PR and go home |
| 00:49 | <bakkot> | I'm gonna stamp it |
| 00:51 | <Michael Ficarra> | I am very much not okay with this. I feel this is akin to willfully introducing a spec bug. |
| 00:54 | <Michael Ficarra> | 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. |
| 00:54 | <bakkot> | We do not have a working solution |
| 00:55 | <bakkot> | After multiple hours of time spent on this |
| 00:55 | <bakkot> | 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 |
| 00:55 | <shu> | it's a good test of the escalation path of having an odd-numbered editors in the group |
| 00:55 | <shu> | we have talked about not requiring unanimity |
| 00:57 | <shu> | i don't see why it's not amicable either, it's just we failed the converge with a compromise? |
| 00:57 | <shu> | like i'm not gonna be harboring grudges |
| 00:57 | <Michael Ficarra> | 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. |
| 00:58 | <bakkot> | "identity from the perspective of the specification" is that thing, no? |
| 00:58 | <Michael Ficarra> | The "two identities" solution satisfied that |
| 00:58 | <shu> | we still have the two identities solution! |
| 00:58 | <shu> | there's just no <dfn>s |
| 00:59 | <Michael Ficarra> | we have two comparisons |
| 00:59 | <Michael Ficarra> | which is a fine thing |
| 00:59 | <Michael Ficarra> | but we also have conditional identity |
| 00:59 | <Michael Ficarra> | which is not fine to me |
| 00:59 | <shu> | arghghhhh |
| 01:00 | <shu> | we have two identities |
| 01:00 | <shu> | not a conditional identity |
| 01:00 | <Michael Ficarra> | "they have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language" |
| 01:00 | <shu> | reusing the same english word "identity" doesn't mean the underlying mental model has conditional identity |
| 01:00 | <shu> | i will try one last time |
| 01:01 | <shu> | consider the <dfn>s to be "identity from the perspective of specification" and "identity from the perspective of ECMAScript language" that correspond exactly to <dfn>specification identity</dfn> and <dfn>language identity</dfn> |
| 01:01 | <shu> | 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 <dfn>s |
| 01:01 | <shu> | where it is confusing, we spell out the full thing |
| 01:01 | <shu> | and it is confusing in exactly one place |
| 01:02 | <shu> | this is not an any less rigorous |
| 01:02 | <shu> | but it is more readable |
| 01:03 | <Michael Ficarra> |
a note in the liveness section? |
| 01:03 | <shu> | in the CanBeHeldWeakly section |
| 01:03 | <shu> | though liveness could use a note as well, though we discussed already multiple times, it actually doesn't matter there |
| 01:04 | <Michael Ficarra> | with my changes, that section doesn't use identity |
| 01:04 | <shu> | my current rebase takes your changes as is, except it refers to identity in the note |
| 01:05 | <bakkot> | I am fine with dropping the reference to identity within the note in CanBeHeldWeakly, if that would help? |
| 01:05 | <shu> | i'd like it there |
| 01:06 | <Michael Ficarra> | okay then I don't understand what your object was to my suggestion of "comparing as if they don't have identity" |
| 01:07 | <Michael Ficarra> | 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 |
| 01:07 | <shu> | what do you mean by "don't use the identity itself anywhere", including in the note? |
| 01:07 | <shu> | let me actually upload the PR and we can go through that |
| 01:08 | <Michael Ficarra> | yeah I don't see a reason why the CanBeHeldWeakly note would need to refer to the identity itself |
| 01:08 | <Michael Ficarra> | already in my PR I made it so that it doesn't |
| 01:08 | <shu> | yeah it doesn't need to |
| 01:09 | <shu> | the reason is i think it captures the rationale. if we don't say that we might as well remove the whole note |
| 01:09 | <Michael Ficarra> | I would like to see your alternative note |
| 01:10 | <Michael Ficarra> | I think my edit to the note captures the entire rationale |
| 01:12 | <shu> | hmm |
| 01:12 | <shu> | https://github.com/syg/ecma262/commit/dece95561adbd5d1ef994f32a3f95e6da53ef37e |
| 01:12 | <shu> | i can't figure out how to create a clean PR against acutmore's branch |
| 01:12 | <shu> | but that commit has it in my repo |
| 01:17 | <shu> | 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 |
| 01:18 | <Michael Ficarra> | 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? |
| 01:19 | <shu> | what was your suggestion, the "as if"? |
| 01:19 | <Michael Ficarra> | yes |
| 01:19 | <shu> | i'll explain again why i have issue with "as if" |
| 01:19 | <shu> |
first, recall that this is the mental model i intend ^ |
| 01:20 | <shu> | 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" |
| 01:20 | <Michael Ficarra> | 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) |
| 01:21 | <shu> | i disagree on the clarity of how it happens |
| 01:21 | <shu> | the how is the implementation detail |
| 01:21 | <shu> | anyway that's a tangent |
| 01:21 | <shu> | 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 |
| 01:22 | <shu> | which is not the mental model that we have |
| 01:22 | <Michael Ficarra> | yes, you essentially "look up" the comparison operation based on which identity you're looking to operate on |
| 01:23 | <Michael Ficarra> | that doesn't seem like a great thing to do when it can be ambiguous at times! |
| 01:23 | <shu> | it's the other way: the comparison determines the identity you're using |
| 01:23 | <shu> | i don't have a value and just be like "let me contemplate its identity" |
| 01:23 | <shu> | it's always driven by what comparison operation you're doing |
| 01:24 | <shu> | anyway i'm not rexplaining the whole thing again, i don't have time |
| 01:24 | <Michael Ficarra> | but in the note you wrote, you do discuss whether something has identity or not, which is not just a comparison |
| 01:25 | <shu> | what |
| 01:25 | <shu> | "has/has not identity" == equivalence classes for comparison operations |
| 01:26 | <shu> | are you really confused by the phrase "has identity" used without direct juxtaposition with a comparison operation? |
| 01:28 | <shu> | 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"? |
| 01:28 | <shu> | is that the confusion? |
| 01:28 | <Michael Ficarra> | yeah possibly |
| 01:29 | <bakkot> |
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 |
| 01:30 | <shu> | anyway i'm going home |
| 01:30 | <shu> | the rebased 2777 is up at https://github.com/syg/ecma262/tree/symbols-as-weakmap-keys |
| 01:31 | <bakkot> | 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 |
| 01:31 | <bakkot> | and so we can stop talking about this |
| 01:31 | <bakkot> | it is just not worth spending this amount of time on this question |
| 01:37 | <bakkot> | 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. |
| 01:39 | <Michael Ficarra> |
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? |
| 01:41 | <Michael Ficarra> | bakkot: how is identity from the perspective of ecmascript code observed? |
| 01:45 | <jmdyck> | (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.) |
| 01:46 | <bakkot> | Object.is, mainly |
| 01:47 | <bakkot> | 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) |
| 01:50 | <Michael Ficarra> | then I think we should explore how we can talk about just the comparison operations and not introduce a second identity |
| 01:51 | <bakkot> | I do not think that |
| 01:51 | <bakkot> | I think we should distinguish between identity from the perspective of the spec and identity from the perspective of the language |
| 01:52 | <bakkot> | 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 |
| 01:52 | <bakkot> | fortunately these differ in exactly one case, which is spelled out explicitly, at which point you know all there is to know |
| 01:52 | <bakkot> | this is the ideal situation |
| 01:53 | <Michael Ficarra> | I am feeling more lost now than ever |
| 01:53 | <bakkot> | 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 |
| 01:54 | <Michael Ficarra> | SameValue distinguishes symbols (any symbols) based on their spec identity. How does that not expose the spec identity to the language? |
| 01:54 | <Michael Ficarra> | 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. |
| 01:55 | <bakkot> | I do not understand the question? |
| 01:55 | <bakkot> | I did not say anything about "exposing the spec identity to the language" at any point afaict |
| 01:56 | <Michael Ficarra> |
|
| 01:56 | <Michael Ficarra> | what case are we talking about? |
| 01:56 | <bakkot> | Symbol.for symbols |
| 01:56 | <Michael Ficarra> | what about them |
| 01:57 | <bakkot> | and the difference comes from the definition of identity: "may be manifest anywhere simply by fully describing their characteristics" |
| 01:57 | <bakkot> | within the language, Symbol.for symbols can be manifest by describing them |
| 01:57 | <bakkot> | within the spec, this is not true |
| 01:58 | <bakkot> | so within the language, Symbol.for symbols do not have identity; within the spec, they do |
| 01:58 | <Michael Ficarra> | when we say that about identity, we're not making it a derived characteristic based on that, we're just stating an implication |
| 01:59 | <bakkot> | "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 |
| 01:59 | <Michael Ficarra> | the only thing stopping you from manifesting a value anywhere is your inability to describe the indescribable identity |
| 02:00 | <bakkot> | yes but that thing is... the whole point? |
| 02:00 | <Michael Ficarra> | that's where we're defining equality (piecewise) |
| 02:00 | <bakkot> | ok? |
| 02:00 | <bakkot> | that does not contradict anything I said |
| 02:00 | <bakkot> | within the language, Symbol.for symbols can be manifest by describing them |
| 02:00 | <bakkot> | within the spec, this is not true |
| 02:01 | <bakkot> | 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 |
| 02:03 | <Michael Ficarra> | within the language, Symbol.for symbols can be retrieved using a subset of their characteristics that makes them unique among all Symbol.for symbols |
| 02:03 | <Michael Ficarra> | that is not the same as fully describing them |
| 02:05 | <bakkot> | as a reader of the spec, unless you are a philosopher, it is most useful to think of that as fully describing them. |
| 02:06 | <Michael Ficarra> | regardless, that is the property that Shu cares about for liveness and that is what we should say |
| 02:06 | <Michael Ficarra> | we should stop trying to relate this to spec identity |
| 02:07 | <Michael Ficarra> | we want a separate concept |
| 02:07 | <bakkot> | 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 |
| 02:08 | <bakkot> | and Symbol.for symbols don't participate in liveness and so you don't need even need to think about the edge case |
| 02:09 | <Michael Ficarra> | 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 |
| 02:10 | <Michael Ficarra> | 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 |
| 02:10 | <bakkot> | that note is fine for the "can be used as a weak reference" case, certainly |
| 02:10 | <Michael Ficarra> | call it whatever you like, but we should at least call it out explicitly |
| 02:11 | <Michael Ficarra> | what's the other case? |
| 02:11 | <Michael Ficarra> | maybe I just don't understand the other case then |
| 02:12 | <bakkot> | there's the definition of identity, and liveness |
| 02:12 | <bakkot> | 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 |
| 02:13 | <Michael Ficarra> | and what does that accomplish? |
| 02:13 | <bakkot> | what does... what accomplish? |
| 02:13 | <Michael Ficarra> |
|
| 02:14 | <bakkot> | what does his PR accomplish? it corrects the definition of identity so that the edge case of Symbol.for symbols is explained |
| 02:15 | <Michael Ficarra> | the PR description says
which you just agreed is already solved by my changes to CanBeHeldWeakly, so what else is it accomplishing? |
| 02:15 | <bakkot> |
|
| 02:16 | <bakkot> | also I am assuming your note gets reworded to take that into account |
| 02:17 | <Michael Ficarra> | I don't know what literally anything at all means anymore |
| 02:17 | <Michael Ficarra> | there is no edge case of Symbol.for symbols for identity |
| 02:17 | <Michael Ficarra> | they have identity, period |
| 02:18 | <Michael Ficarra> | 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" |
| 02:18 | <Michael Ficarra> | why does anything else need to change? |
| 02:18 | <bakkot> | what is the other concept? |
| 02:19 | <Michael Ficarra> | "suitable for use as a weak reference" |
| 02:19 | <bakkot> | that concept is the concept of having identity from the perspective of the language |
| 02:19 | <bakkot> | and the reason that those agree is because the relevant fact is "can be manifest without prior reference" |
| 02:20 | <bakkot> | 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 |
| 02:20 | <Michael Ficarra> | for immutable values, it is not observable from the language whether something has identity, only how it compares |
| 02:21 | <Michael Ficarra> | this is why you and Shu both keep saying "well Strings could have identity if we wanted them to" |
| 02:21 | <Michael Ficarra> | sure, but we say that they don't |
| 02:22 | <Michael Ficarra> | we also say that symbols do |
| 02:22 | <bakkot> | Strings could have identity from the perspective of the spec, not the language |
| 02:22 | <bakkot> | strings cannot have identity from the perspective of the language |
| 02:22 | <bakkot> | because they can be manifest without prior reference |
| 02:22 | <Michael Ficarra> | 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 |
| 02:23 | <bakkot> | "has identity" is equivalent to "cannot be manifest without prior reference" |
| 02:23 | <Michael Ficarra> | 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 |
| 02:23 | <bakkot> | no they could not |
| 02:24 | <Michael Ficarra> | 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) |
| 02:25 | <Michael Ficarra> | 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? |
| 02:25 | <Michael Ficarra> | but there's not |
| 02:25 | <Michael Ficarra> | the user has opaque black box comparison functions |
| 02:26 | <bakkot> | we would be doing a disservice to readers of the spec if we said "they may or may not have identity" |
| 02:26 | <bakkot> | 3 should not have identity |
| 02:26 | <bakkot> | strings should not have identity |
| 02:26 | <bakkot> | Symbol.for symbols should not have identity |
| 02:26 | <bakkot> | for exactly the same reasons in every case |
| 02:27 | <Michael Ficarra> | but Symbol.for symbols are symbols, whether we like it or not |
| 02:27 | <bakkot> | ... so? |
| 02:27 | <Michael Ficarra> | so when we create a symbol, it has identity |
| 02:27 | <bakkot> | no it doesn't |
| 02:27 | <Michael Ficarra> | when we place it in the GlobalSymbolRegistry, it cannot just lost identity |
| 02:27 | <bakkot> | it does within the spec |
| 02:27 | <bakkot> | it does not within the language |
| 02:27 | <Michael Ficarra> | that's what I'm talking about |
| 02:27 | <Michael Ficarra> | a spec value can't go from having an identity to not having an identity |
| 02:28 | <bakkot> | whether a thing has identity depends on your perspective |
| 02:28 | <Michael Ficarra> | and since we don't give the language fictional symbols, they must have identity too |
| 02:28 | <bakkot> | please see my earlier example of strings-as-List |
| 02:29 | <bakkot> | 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 |
| 02:29 | <Michael Ficarra> |
|
| 02:30 | <Michael Ficarra> | from the perspective of the language, it is unknowable |
| 02:30 | <shu> | 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 |
| 02:30 | <shu> | michael, i implore you, please take a step back and consider the goal |
| 02:30 | <bakkot> | 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. |
| 02:31 | <Michael Ficarra> | I agree, and it's fine to say that |
| 02:31 | <Michael Ficarra> | in fact, we should |
| 02:31 | <bakkot> | ok |
| 02:31 | <Michael Ficarra> | strings do not have identity because we say so |
| 02:32 | <shu> | in the spec? |
| 02:32 | <Michael Ficarra> | but that means we can't call the spec things strings |
| 02:32 | <bakkot> | strings within the spec do not have identity because we say so |
| 02:32 | <bakkot> | if we defined them as Lists, they would have identity within the spec |
| 02:32 | <shu> | precisely |
| 02:32 | <shu> | and doing so is in fact, an editorial change |
| 02:32 | <bakkot> | and, as you say, it is not knowable whether they have identity within the language |
| 02:32 | <bakkot> | 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? |
| 02:32 | <bakkot> | my position is, that would do a disservice to readers. |
| 02:32 | <Michael Ficarra> | then we can't just pass these things in to the language |
| 02:33 | <bakkot> | and readers should be told that, in fact, they do not have identity within the language. |
| 02:33 | <shu> | then we can't just pass these things in to the language |
| 02:34 | <Michael Ficarra> | the language values are not virtual, they are values in our spec universe just like any other |
| 02:34 | <Michael Ficarra> | values that all either have spec identity or do not |
| 02:34 | <bakkot> | that's correct |
| 02:34 | <bakkot> | in this world, strings have spec identity. |
| 02:34 | <shu> | in the strings as Lists world, they have spec identity, yes |
| 02:35 | <bakkot> | 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 |
| 02:35 | <shu> | bb in an hour, but again, michael, i implore you to take a step back and reconsider the goal of a specification |
| 02:35 | <shu> | of a programming language, that is |
| 02:36 | <Michael Ficarra> | is it not to be able to answer questions about how an engine behaves when given a program? |
| 02:37 | <Michael Ficarra> | to do that, we need to be able to say things like "if A is B, do this", but what "is" means is important |
| 02:38 | <bakkot> | we have not made the definition of "is" confusing |
| 02:38 | <bakkot> | every use of the word "is" within the specification is within the specification |
| 02:38 | <bakkot> | we have said which values have identity from the perspective of the specification |
| 02:38 | <bakkot> | there is absolutely zero ambiguity here |
| 02:38 | <Michael Ficarra> | symbols |
| 02:38 | <Michael Ficarra> | symbols have identity |
| 02:39 | <bakkot> | from the perspective of the specification, yes, that's true |
| 02:39 | <Michael Ficarra> | those same symbols which appear as reified values in the language |
| 02:39 | <bakkot> | that is also true |
| 02:39 | <bakkot> | I am waiting for you to say a thing which conflicts with Shu's PR |
| 02:39 | <Michael Ficarra> | there are other questions you can ask about the symbols, like "is this symbol eligible for use as a weak reference" |
| 02:40 | <bakkot> | again that is true |
| 02:40 | <Michael Ficarra> | and those answers can even change over time for the same symbol |
| 02:40 | <bakkot> | not for that particular question, no |
| 02:41 | <Michael Ficarra> | don't, given the language as is, sure |
| 02:41 | <Michael Ficarra> | but theoretically could |
| 02:41 | <Michael Ficarra> | should be allowed by the framework we're building, surely |
| 02:41 | <bakkot> | uh |
| 02:41 | <bakkot> | why |
| 02:42 | <bakkot> | like, it's true that if there were an entirely different conceptual model for weak references, things could be otherwise |
| 02:42 | <bakkot> | 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 |
| 02:42 | <Michael Ficarra> | I mean sure, whatever you like |
| 02:46 | <Michael Ficarra> | what value does "have identity from the perspective of the language" provide over "eligible for use in a weak map"? |
| 02:47 | <bakkot> |
|
| 02:47 | <bakkot> | 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 |
| 02:48 | <bakkot> | 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 |
| 02:48 | <bakkot> | so the spec should tell you this important fact about Symbol.for symbols when it is talking about identity |
| 02:49 | <bakkot> | "this important fact" being that they do not have identity from the perspective of the language |
| 02:49 | <bakkot> | 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 |
| 02:51 | <Michael Ficarra> | a difference being that all things that are a certain kind of thing either do or do not have identity |
| 02:52 | <bakkot> | I don't know what that sentence means |
| 02:52 | <bakkot> | from the perspective of the spec, they have identity |
| 02:52 | <bakkot> | from the perspective of the language, they do not |
| 02:53 | <Michael Ficarra> | 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 |
| 02:54 | <bakkot> | ok, so Symbol.for symbols have identity from the perspective of the spec, great |
| 02:54 | <bakkot> | but they do not have identity from the perspective of the language |
| 02:54 | <bakkot> | that is compatible with what you said |
| 02:55 | <bakkot> | and is an important fact readers should be told |
| 02:55 | <bakkot> | this is what shu's PR does |
| 03:01 | <shu> | 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 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 |
| 03:03 | <shu> | 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) |
| 03:04 | <Michael Ficarra> | what work is "for the purposes of equality comparison" doing there? |
| 03:04 | <Michael Ficarra> | I don't get that |
| 03:04 | <shu> | sorry, let me finish first |
| 03:04 | <shu> | then i'll address that |
| 03:06 | <shu> | 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 |
| 03:07 | <shu> | 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 |
| 03:08 | <shu> | i feel you're getting hangups by treating specification identity as the thing that should be "driving up" |
| 03:09 | <Michael Ficarra> | yeah, probably, but that's our medium, what else could we do? |
| 03:10 | <shu> | what work is "for the purposes of equality comparison" doing there? ==" |
| 03:10 | <Michael Ficarra> | 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 |
| 03:10 | <Michael Ficarra> | and maybe whether or not we can get away with just talking about comparisons and never even introducing it |
| 03:11 | <shu> | yeah, probably, but that's our medium, what else could we do? |
| 03:11 | <shu> | where we messed up, inadvertently, is the introduction of Symbol.for symbols |
| 03:12 | <shu> | 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" |
| 03:12 | <shu> | and recognize that it is in fact not contradictory |
| 03:13 | <shu> | and because spec identity is just an implementation detail |
| 03:14 | <Michael Ficarra> | 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? |
| 03:15 | <shu> | i don't follow |
| 03:15 | <shu> | i don't follow the second question |
| 03:15 | <shu> | and it is insufficient, in a disservice-to-the-reader way |
| 03:15 | <shu> | because identity is the concept that ties together our maintaining the design choice we already made for weak things: no primitives |
| 03:16 | <shu> | it's not because they are primitives, it's because they don't have identity |
| 03:16 | <Michael Ficarra> | I'm still not understanding what problem remains unsolved by just merging https://github.com/acutmore/ecma262/pull/3 |
| 03:16 | <shu> | i feel like both kevin and i have both repeatedly said "disservice to the reader" |
| 03:16 | <shu> | i think it is important to get across the design rationale being identity |
| 03:16 | <shu> | identity and weakness are closely tied |
| 03:17 | <Michael Ficarra> | 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 |
| 03:17 | <shu> | i find that to be a disservice to the reader |
| 03:18 | <Michael Ficarra> | why does weakness have to be tied to a concept that we call identity? |
| 03:18 | <shu> | we can disagree on that particular value judgment, but given that it's 2-to-1 and we've discussed this at length... |
| 03:18 | <Michael Ficarra> | why can't it be tied to this other similar concept? |
| 03:18 | <shu> | because the connection is well understood in PLs and compilers and VMs |
| 03:18 | <Michael Ficarra> | but this PL is bad and has separated it in design |
| 03:19 | <shu> | it hasn't separated, Symbol.for doesn't have identity |
| 03:19 | <shu> | it's "bad" in the sense that its type system doesn't align on identity or identity-less boundaries |
| 03:20 | <shu> | you have stipulated that it is inviolate that all values of a language type must have or not have identity |
| 03:20 | <shu> | that is, however, not a fact of the world |
| 03:20 | <Michael Ficarra> | well additionally, the way the language is spec'd, many meta-level concepts are exposed directly at the fiction level |
| 03:20 | <shu> | exposed directly at the language level you mean? |
| 03:20 | <shu> | meta-level is the fiction level |
| 03:20 | <Michael Ficarra> | lol I guess it depends on perspective |
| 03:21 | <shu> | not in this case |
| 03:21 | <shu> | the spec defines "spec type" as a thing |
| 03:21 | <shu> | that we learned earlier today that you did not agree with |
| 03:21 | <Michael Ficarra> | to the spec, all spec things are real and the language is a virtual thing |
| 03:21 | <shu> | i'm sorry michael i'm not going to go on a tangent to dive into "real" |
| 03:21 | <Michael Ficarra> | I was just not aware that it excluded language values, I thought it was defined to be superset relationship |
| 03:22 | <shu> | i think that is more signal that your mental model is in fact not the spec's |
| 03:22 | <shu> | nor mine and kevin's |
| 03:22 | <shu> | and given that i think you actually understand our view at this point |
| 03:22 | <shu> | i'd like to move forward with my PR |
| 03:23 | <shu> | (conversely i think we also understand yours) |
| 03:24 | <shu> | 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 |
| 03:24 | <Michael Ficarra> | 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 |
| 03:25 | <shu> | sure, let's draw out the matrix |
| 03:25 | <Michael Ficarra> | I don't think I optimise for rigour, I just think identity, of all places, is a place that really needs it |
| 03:26 | <shu> |
|
| 03:26 | <Michael Ficarra> | I mean, before we added the identity section, we actually experienced cases of ambiguity arising from it |
| 03:26 | <shu> | sorry, not rigot, i misspoke, i actually meant formality |
| 03:26 | <shu> | formality of the surface language |
| 03:26 | <shu> | i still contend the rigor of the 2-identity model exists in my current PR |
| 03:27 | <shu> | so my concrete proposal is: if kevin can live with "spec identity" and "language identity", let's revert back to that state |
| 03:27 | <bakkot> |
it does not make me happy; it's more confusing than the current PR |
| 03:27 | <shu> | if he cannot, let's go with my current PR, and you should consider yourself overruled michael, under protest |
| 03:28 | <bakkot> | specifically I really do not want to have a table |
| 03:28 | <shu> | is that reasonable to everyone as the playbook to get an actionable conclusion? |
| 03:28 | <shu> | oh i can remove that table and use prose |
| 03:28 | <Michael Ficarra> | bakkot: we could do away with the table |
| 03:28 | <shu> | and just have a special sentence for Symbol.for |
| 03:28 | <bakkot> | that's what we currently have |
| 03:28 | <Michael Ficarra> | I also had prose suggestions if we were going that route |
| 03:28 | <shu> | we don't currently have <dfn>s for spec and language identity |
| 03:28 | <bakkot> | currently meaning in your PR |
| 03:28 | <shu> | i think michael is saying let's bring back <dfn>s for it |
| 03:28 | <Michael Ficarra> | I just didn't bother leaving them until I kenw which way we were going |
| 03:29 | <bakkot> | I definitely do not want those terms dfn'd or used anywhere outside of the section on identity |
| 03:29 | <bakkot> | I can live with using those terms, but not dfn'ing them, within the section |
| 03:29 | <bakkot> | though that seems worse than what we have in the PR |
| 03:29 | <Michael Ficarra> | 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 |
| 03:29 | <shu> | yes |
| 03:30 | <Michael Ficarra> | but I would rather be more clear that these are two concepts |
| 03:30 | <Michael Ficarra> | not one conditional concept, which is how I fear it would be read |
| 03:30 | <shu> | okay here's how we can thread the needle |
| 03:31 | <shu> |
|
| 03:31 | <Michael Ficarra> | yeah that sounds like it would be good |
| 03:32 | <bakkot> | I can live with that |
| 03:32 | <shu> | excellent |
| 03:32 | <shu> | i will do that tomorrow |
| 03:32 | <shu> | i am tired now |
| 03:32 | <Michael Ficarra> | 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 |
| 03:33 | <Michael Ficarra> | k I gotta go too |
| 03:34 | <shu> | talk tomorrow |
| 16:45 | <ljharb> | will language identity still be dfn'd? |
| 17:32 | <shu> | no |
| 17:32 | <shu> | just <em>'d |
| 17:55 | <ljharb> | :-/ that's unfortunate |
| 20:34 | <shu> | new commit up, PTAL bakkot Michael Ficarra : https://github.com/tc39/ecma262/pull/3027 |
| 21:01 | <Michael Ficarra> | I would probably swap the order of the Symbol.for part, but otherwise LGTM |
| 21:05 | <Michael Ficarra> |
|
| 21:06 | <Michael Ficarra> | can you share your updates to CanBeHeldWeakly? |
| 21:19 | <shu> | my git fu is not strong enough |
| 21:19 | <shu> | how do i get a clean PR against acutmore's branch |
| 21:19 | <shu> | (how did you do it?) |
| 21:22 | <jmdyck> | You mean you already have the commit, it's just the creation of the PR that you're asking about? |
| 21:24 | <shu> | i'm asking specifically about #2777 |
| 21:24 | <shu> | 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 |
| 21:25 | <shu> | i can like... squash everything and push to a new branch |
| 21:26 | <jmdyck> | Rather than rebase it on your work, you wouldn't rebase your work on it? |
| 21:26 | <shu> | oh uhhh |
| 21:27 | <shu> | i don't know |
| 21:27 | <shu> | why would i do that? logically my PR should land first |
| 21:28 | <jmdyck> | your PR against 2777's upstream branch should land in that branch before what? |
| 21:36 | <Michael Ficarra> | someone needs to write a "Git for Engineering Directors" book |
| 21:37 | <jmdyck> | (I don't understand what you mean by "land first". first before what?) |
| 21:38 | <shu> | at a high level, the timeline of what i think should happen:
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 |
| 21:38 | <jmdyck> | ah |
| 21:40 | <jmdyck> | Is the point of PR2777 just to accomplish the rebasing of #2777 on your first PR? |
| 21:41 | <shu> | 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 |
| 21:43 | <jmdyck> | so you want to accomplish the rebasing of 2777 before your first PR actually lands? |
| 21:43 | <shu> | that is correct |
| 21:44 | <shu> | Michael Ficarra: swapped |
| 21:45 | <jmdyck> | And the merges in 2777 are complicating the desired rebase? |
| 21:48 | <shu> | also correct |
| 21:49 | <jmdyck> | then I think my git fu is also not strong enough, sorry |
| 21:52 | <jmdyck> | So when the rebase gets to a merge-point, you can't just treat it the same as a rebase conflict? |
| 21:52 | <Michael Ficarra> | I'm sure that I have the requisite git skill, but I don't understand what you're trying to do |
| 21:53 | <shu> | i might be holding it wrong in my mind |
| 21:53 | <shu> | let me just push to my own repo and show you the wording Michael Ficarra |
| 21:53 | <shu> | we can figure out the git surgery later |
| 21:53 | <Michael Ficarra> | lol k |
| 21:56 | <shu> | https://github.com/syg/ecma262/commit/f28058faabad41a4c4a65597cf5927e2e83e3e91 |
| 22:05 | <Michael Ficarra> | 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? |
| 22:05 | <Michael Ficarra> | I'd like to be consistent with that phrasing |
| 22:07 | <Michael Ficarra> | also pull in my grammar fixes in the last sentence:
|
| 22:35 | <shu> | 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? |
| 22:36 | <shu> | ...why? do you think it's ambiguous currently? |
| 22:37 | <shu> | wfm to always spell it out for 2 sentences |
| 22:37 | <shu> | if there were more sentences i don't think i'd want to repeatedly read that phrase over and over |
| 22:37 | <Michael Ficarra> | 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 |
| 22:40 | <shu> |
|
| 22:40 | <shu> | avoid any additional qualifiers |
| 22:40 | <Michael Ficarra> | sounds good |
| 22:44 | <shu> | https://github.com/syg/ecma262/commit/7511eeba7ae2c6ab5e5314bef912d8ac0d9b15c8 |
| 22:47 | <shu> | with that, do we think https://github.com/tc39/ecma262/pull/3027 is ready to merge? |
| 22:48 | <shu> | 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 |
| 22:48 | <Michael Ficarra> | yeah I think so |
| 23:21 | <shu> | ljharb: what's that force push in https://github.com/tc39/ecma262/pull/3027? |
| 23:21 | <shu> | oh kevin has a comment |
| 23:24 | <bakkot> | two comments |
| 23:24 | <bakkot> | lgtm otherwise |
| 23:25 | <bakkot> | also do want to register that this is, IMO, significantly worse than the previous PR which talked about "identity from the perspective of" |
| 23:26 | <bakkot> | but I will suck it up so we can land it |
| 23:26 | <shu> | well the perspective language is still there in the identity section |
| 23:27 | <shu> | just not in the CanBeHeldWeakly note |
| 23:27 | <shu> | and... we just don't use it anywhere else |
| 23:27 | <shu> | and that seems ok |
| 23:27 | <bakkot> | sorry I mean specifically introducing "language identity" and "spec identity" as terms |
| 23:27 | <bakkot> | is bad |
| 23:27 | <bakkot> | I really quite dislike doing that |
| 23:27 | <ljharb> | that force push was me getting ready to merge it |
| 23:27 | <bakkot> | again, not suggesting to change it |
| 23:27 | <bakkot> | just registering displeasure |
| 23:29 | <shu> | yeah i mean, yeah |
| 23:30 | <shu> | ljharb: ah okay let me apply kevin's last comment and we should be gtg |
| 23:33 | <shu> | bakkot: all right, see if the reworded paragraph wfy |
| 23:34 | <bakkot> | lgtm |
| 23:35 | <shu> | okay, i gotta run but will do 2777 tomorrow morning probably |
| 23:35 | <shu> | should be easy |