21:36
<ljharb>
my comcast and verizon is down rn so i won't be in the call, lmk if there's any repo stuff
22:14
<Michael Ficarra>
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?
22:37
<ljharb>
will do
23:13
<shu>
Michael Ficarra: bakkot https://github.com/tc39/ecma262/pull/3027 PTAL
23:17
<bakkot>
nice, I like it
23:25
<shu>
okay let me rebase #2777 on top of this
23:27
<Michael Ficarra>
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."
23:27
<Michael Ficarra>
I don't know if the reader knows what "but do not have identity from the perspective of the ECMAScript language" means
23:27
<shu>
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
23:28
<Michael Ficarra>
I think we should probably talk about what the consequence is instead
23:28
<shu>
the consequence?
23:29
<shu>
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
23:30
<shu>
which should be exceedingly rare
23:30
<Michael Ficarra>
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
23:31
<shu>
what
23:31
<shu>
we say "specification or ECMAScript language value" all the time
23:31
<shu>
or am i misunderstanding what you mean by mixing
23:32
<Michael Ficarra>
we do?
23:32
<Michael Ficarra>
not that I see
23:33
<shu>
"Types are further subclassified into ECMAScript language types and specification types"
23:33
<shu>
what do you think that sentence means
23:34
<shu>
like, there's a list of language types, which are inhabited by the language values
23:34
<shu>
and the other stuff are specification types
23:34
<shu>
and spec values
23:34
<Michael Ficarra>
what do we call the type of all values used in the spec?
23:35
<Michael Ficarra>
I have been calling that specification values
23:35
<shu>
i don't think we have need of that word
23:35
<shu>
that is not what specification values as used means
23:35
<shu>
i guess those are just "values" simplicter
23:36
<shu>
"A specification type corresponds to meta-values that are used within algorithms to describe the semantics of ECMAScript language constructs and ECMAScript language types."
23:36
<Michael Ficarra>
I see
23:42
<shu>
with that clarification, any other concerns?
23:43
<Michael Ficarra>
I'm writing a suggestion
23:45
<Michael Ficarra>
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."
23:45
<Michael Ficarra>
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?
23:46
<shu>
well this is where we fucked up with designing symbols
23:46
<shu>
Symbol.for symbols are really nothing like Symbols
23:46
<shu>
regular Symbols have no other qualities than their identity
23:46
<shu>
Symbol.for symbols have the quality of their string contents
23:46
<shu>
(from the perspective of the language)
23:46
<bakkot>
symbols have descriptions
23:47
<bakkot>
not just identity
23:47
<Michael Ficarra>
okay so they will have a unique [[description]]?
23:47
<bakkot>
and conveniently, all Symbol.for descriptions are unique
23:47
<bakkot>
so yes
23:48
<shu>
in fact i wonder if that would be an editorial improvement
23:48
<Michael Ficarra>
shu: what do you think about my suggestion?
23:48
<bakkot>
(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)
23:48
<shu>
wfm, only quibble is i'd move "from the perspective of the ECMAScript language" to the start of the second clause
23:50
<Michael Ficarra>
bakkot: they may not have a description though, in which case the only thing distinguishing them is their identity
23:50
<shu>
but all Symbol.for symbols certainly do
23:50
<bakkot>
descriptions don't distinguish them but it is a quality they have
23:50
<Michael Ficarra>
but as long as smybol.for symbols all have descriptions and they're all unique, we're good
23:50
<bakkot>
that is the case, yup
23:50
<bakkot>
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
23:50
<shu>
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]]
23:51
<shu>
Michael Ficarra: maybe you can say more why you don't like the sentence as is
23:51
<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
23:52
<bakkot>
in ES code, but not in the spec
23:52
<bakkot>
that is what "have identity from the perspective of this specification but do not have identity from the perspective of the ECMAScript language" means
23:52
<bakkot>
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
23:53
<Michael Ficarra>
bakkot: well that's why in my original approach that's basically what I said
23:54
<bakkot>
we are going with Shu's approach though
23:54
<bakkot>
so that is why I like the thing currently in the PR, and not the thing you suggest
23:54
<Michael Ficarra>
I thought we were going with a hybrid
23:54
<bakkot>
uh
23:55
<bakkot>
ok we don't need to resolve this confusion
23:55
<bakkot>
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
23:55
<shu>
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
23:55
<Michael Ficarra>
were we not planning on still pulling in https://github.com/acutmore/ecma262/pull/3/files?
23:55
<Michael Ficarra>
yes, Ashley's PR already has that predicate
23:55
<bakkot>
yes we are
23:56
<bakkot>
I'm only talking about shu's PR right now
23:56
<Michael Ficarra>
and my PR adds context onto it, that's all
23:56
<shu>
well, not the changes to the identity section of that PR
23:56
<shu>
the rest of it yes
23:56
<Michael Ficarra>
yes, the changes to the identity section just reverted Ashley's changes, they weren't a suggestion
23:56
<shu>
ah okay, then yes
23:57
<Michael Ficarra>
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"
23:57
<Michael Ficarra>
considering we will provide that information in context, do you still feel that way?
23:57
<shu>
i do now that kevin points it out
23:57
<bakkot>
yes
23:57
<shu>
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
23:59
<shu>
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