3 ms·

They’re the same example. The reason a given string is equal to the same value and the same isn’t true of arrays (in JS) is precisely because the latter might c

They’re the same example. The reason a given string is equal to the same value and the same isn’t true of arrays (in JS) is precisely because the latter might change and the former can’t. That’s exactly the semantics of values in the language: immutable things with equal state are equal (notwithstanding NaN which has special equality semantics), nothing mutable is equal unless it’s the same reference and will always be equal.

TeMPOraL 4y ago
What are the actual semantics here? Is JS automatically interning strings as symbols these days, or is the == operator comparing strings character by character, and arrays only by pointer (aka "object identity")?
- eyelidlessness 4y ago
  The semantics are that primitives (string, number, boolean, undefined, symbol) can be compared by value and everything else (object, except null) is a reference type with pointer identity regardless of the value. This might change in a meaningful way for collections if the records/tuples proposal succeeds. But even then those types will be considered primitives and won’t be allowed to contain reference types either. Strings are primitives in JS, not just these days. They’re always value-equal unless they’re boxed (eg new String, which nobody ever does unless they’re doing something really weird). === would work the same way. Edit: I guess more to the point about how strings differ from arrays of string bytes… the semantics are that they’re only superficially similar. They’re both a sequential collection of things that might be a string character (or part of one), and they might have some getter names in common with similar behaviors, but that’s where their similarities end.
  - TeMPOraL 4y ago
    > Strings are primitives in JS, not just these days. Right. What I meant is whether they're interned - i.e. stuffed in a global table, in which strings (or at least string constants) are automatically looked up on parsing. If they were interned, both instances of "hello" in the expression "hello" == "hello" would parse into the same object, i.e. two pointers referencing the same character array, and thus could be compared in O(1) by comparing pointer addresses, instead of checking individual characters. This is how symbols (a distinct type from strings) are implemented in Lisp languages. I've heard some languages do that automatically as optimization for small strings. I vaguely recall JavaScript was supposed to get symbols too, a while ago. Anyway, per yours and sibling comments, I see the difference between strings and arrays is effectively determined by how operator == treats them.
    - tuukkah 4y ago
      JavaScript has a symbol type but I think it's different. I don't see the JS spec saying anything about interning or time complexity. Here's some talk about how JS implementations intern compile-time constants and nothing else: https://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning https://stackoverflow.com/questions/5276915/do-common-javasc...
    - jholman 4y ago
      I agree with the sibling comment that there is nothing in the spec saying whether or not strings are interned, and commend the reference there. Also, you probably meant the === operator, because discussing the == operator is a whole extra bag of worms.
- tuukkah 4y ago
  The result of == on strings is defined as comparison UTF-16 code unit by UTF-16 code unit (non-normalised). The result of == on what the spec calls "Object values" (including arrays) is by identity. Here's the spec: https://tc39.es/ecma262/#sec-samevaluenonnumber https://tc39.es/ecma262/#sec-samevaluenonnumber > 7.2.12 SameValueNonNumber ( x, y ) [...] > 5. If x is a String, then > a. If x and y are exactly the same sequence of code units (same length and same code units at corresponding indices), return true; otherwise, return false. [...] > 8. If x and y are the same Object value, return true. Otherwise, return false.
  - eyelidlessness 4y ago
    Is it okay if I snickered? Because I did snicker.
    - tuukkah 4y ago
      Sure, although trying to decipher the spec more typically makes me want to cry. (Where do they define the "sameness" of "Object values"?)

TeMPOraL 4y ago

What are the actual semantics here? Is JS automatically interning strings as symbols these days, or is the == operator comparing strings character by character, and arrays only by pointer (aka "object identity")?

eyelidlessness 4y ago
The semantics are that primitives (string, number, boolean, undefined, symbol) can be compared by value and everything else (object, except null) is a reference type with pointer identity regardless of the value. This might change in a meaningful way for collections if the records/tuples proposal succeeds. But even then those types will be considered primitives and won’t be allowed to contain reference types either. Strings are primitives in JS, not just these days. They’re always value-equal unless they’re boxed (eg new String, which nobody ever does unless they’re doing something really weird). === would work the same way. Edit: I guess more to the point about how strings differ from arrays of string bytes… the semantics are that they’re only superficially similar. They’re both a sequential collection of things that might be a string character (or part of one), and they might have some getter names in common with similar behaviors, but that’s where their similarities end.
- TeMPOraL 4y ago
  > Strings are primitives in JS, not just these days. Right. What I meant is whether they're interned - i.e. stuffed in a global table, in which strings (or at least string constants) are automatically looked up on parsing. If they were interned, both instances of "hello" in the expression "hello" == "hello" would parse into the same object, i.e. two pointers referencing the same character array, and thus could be compared in O(1) by comparing pointer addresses, instead of checking individual characters. This is how symbols (a distinct type from strings) are implemented in Lisp languages. I've heard some languages do that automatically as optimization for small strings. I vaguely recall JavaScript was supposed to get symbols too, a while ago. Anyway, per yours and sibling comments, I see the difference between strings and arrays is effectively determined by how operator == treats them.
  - tuukkah 4y ago
    JavaScript has a symbol type but I think it's different. I don't see the JS spec saying anything about interning or time complexity. Here's some talk about how JS implementations intern compile-time constants and nothing else: https://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning https://stackoverflow.com/questions/5276915/do-common-javasc...
  - jholman 4y ago
    I agree with the sibling comment that there is nothing in the spec saying whether or not strings are interned, and commend the reference there. Also, you probably meant the === operator, because discussing the == operator is a whole extra bag of worms.
tuukkah 4y ago
The result of == on strings is defined as comparison UTF-16 code unit by UTF-16 code unit (non-normalised). The result of == on what the spec calls "Object values" (including arrays) is by identity. Here's the spec: https://tc39.es/ecma262/#sec-samevaluenonnumber https://tc39.es/ecma262/#sec-samevaluenonnumber > 7.2.12 SameValueNonNumber ( x, y ) [...] > 5. If x is a String, then > a. If x and y are exactly the same sequence of code units (same length and same code units at corresponding indices), return true; otherwise, return false. [...] > 8. If x and y are the same Object value, return true. Otherwise, return false.
- eyelidlessness 4y ago
  Is it okay if I snickered? Because I did snicker.
  - tuukkah 4y ago
    Sure, although trying to decipher the spec more typically makes me want to cry. (Where do they define the "sameness" of "Object values"?)