| 14:00 | <jmdyck> | Let me see if I've got this straight... |
| 14:01 | <jmdyck> | Symbols can be put into 3 categories: |
| 14:01 | <jmdyck> |
|
| 14:03 | <jmdyck> |
|
| 14:03 | <jmdyck> |
|
| 14:13 | <jmdyck> | Symbols created by the Symbol constructor have language identity, the others don't. So Symbols created by Symbol() are suitable for use as a weak reference, and the others aren't, except that well-known symbols are. |
| 14:16 | <jmdyck> | So in the one place that the spec uses the concept of 'language identity' (in the Note for CanBeHeldWeakly), it isn't even exactly the necessary concept. |
| 15:00 | <jmdyck> | (Actually, the 'Identity' section implies that well-known symbols have language identity, but I don't see how that could be. E.g., you can manifest @@match just by saying Symbol.match.) |
| 19:42 | <jmdyck> | so.... any thoughts on whether well-known symbols have language identity? |
| 19:46 | <shu> | they do |
| 19:46 | <shu> | kinda by fiat, i guess |
| 19:46 | <shu> | let me see if i can dig up any discussion |
| 19:48 | <shu> | i cannot dig up discussion |
| 19:49 | <jmdyck> | So how to reconcile that with the ability to manifest them without prior reference? |
| 19:50 | <shu> | i can only offer the practical GC difference, which is that well-known symbols are eternal roots and there is a bounded set of them. it doesn't matter much whether we say they have or have not language identity, there is no danger in holding them weakly because they will never be collected |
| 19:51 | <shu> | it was decided it was easier to think of them as having identity, since that's the line we wanted to draw for CanBeHeldWeakly, and identity was the best-matched concept to explain the line to draw |
| 19:51 | <shu> | Symbol.for symbols are unbounded and users can generate new ones (the "manifesting") |
| 19:51 | <shu> | i don't think of "manifesting" as simply referencing |
| 19:51 | <shu> | i don't "manifest" the built-in Object by typing Object |
| 19:52 | <jmdyck> | Hm, spec doesn't define "manifest". |
| 19:52 | <shu> | indeed it does not |
| 19:52 | <shu> | i don't think we have it in us to define manifest either |
| 19:53 | <shu> | but it's something like "causing things to be created that wasn't already there" |
| 19:53 | <shu> | but that is like, a concrete way to think about it, not a spec way to think about it |
| 19:53 | <shu> | the spec does not preclude a world where, for example, the set of all floating point Number values are already there, just floating around |
| 19:54 | <jmdyck> | and that idea doesn't work with "Values without identity may be manifest ..." |
| 19:54 | <shu> | and each time you need one you just "reference" it instead of "manifest" it |
| 19:54 | <shu> |
how so? |
| 19:55 | <jmdyck> | Well, like in your example, 3.2 doesn't cause a Number value to be 'created'. |
| 19:56 | <shu> | the point is that concretely, in the real world where JS is implemented, it does |
| 19:56 | <shu> | the parallel is stronger with strings |
| 19:56 | <shu> | it is not possible, in a real implementation, to pre-create the infinite set of all possible string values |
| 19:56 | <shu> | the spec does not preclude such an implementation, though |
| 19:57 | <jmdyck> | agree that "causing things to be created that wasn't already there" is an implementation way of thinking about "manifest". |
| 19:57 | <shu> | (it is actually possible, if pointless, to do it for all 64bit floating point values at least) |
| 19:58 | <shu> | but we work backwards -- we're not interested in defining an ontology per se |
| 19:58 | <shu> | we're interested in capturing some way, in the spec, to explain why Symbol.for symbols can't be weak keys |
| 19:59 | <jmdyck> | right, but it seems to me that bringing in the idea of "language identity" is maybe counter-productive |
| 19:59 | <shu> | suggestions welcome, the last time we tried it it was... hard and contentious |
| 19:59 | <jmdyck> | hm |
| 19:59 | <shu> | kevin and i felt "identity" was the right concept, and i continue to feel that way |
| 19:59 | <shu> | most programmers have some intuitive notion of "identity" that mostly matches up |
| 20:00 | <jmdyck> | So you would say that "language identity" perfectly matches the semantics of CanBeHeldWeakly? |
| 20:01 | <shu> | i would, yes |
| 20:01 | <jmdyck> | ok |
| 20:21 | <bakkot> | (although we chose "CanBeHeldWeakly" instead of my [or someone's anyway] original "HasIdentity" specifically to avoid needing that to be true) |
| 20:23 | <jmdyck> | I think I'd have difficulty justifying the statement "Symbols produced by Symbol.for do not have language identity" using only what the spec says about identity. (I note that the spec doesn't try to justify it.) |
| 20:23 | <bakkot> | Symbol.for symbols are very much an edge case, basically the edge case |
| 20:24 | <jmdyck> | yup |
| 20:24 | <bakkot> | it depends on whether you think of Symbol.for as being a registry which holds the symbols it has produced, or being a factory which produces indistinguishable values when given the same input |
| 20:24 | <bakkot> | both are compatible with the observable behavior |
| 20:24 | <bakkot> | engines I think tend to take the latter perspective, which means they do not have identity because you can manifest the values without having had a handle to them |
| 20:26 | <jmdyck> | The spec certainly encourages thinking of the registry. |
| 20:26 | <bakkot> | yeah. |
| 20:28 | <bakkot> | might be worth adding a sentence to the description of Symbol.for mentioning the alternative perspective, I think |
| 20:38 | <jmdyck> | https://github.com/tc39/ecma262/pull/3217 has some suggestions, but doesn't do anything radical like do away with the concept of language identity. |
| 20:39 | <jmdyck> | or attempt to justify "Symbol.for Symbols don't have lang identity" |
| 21:53 | <shu> | FYI i can only stay for 30 minutes today |