3 ms·

> I don't think you've chosen a good example. This comment makes zero sense. Here's the part that you quoted from the OP in this thread: >> For example, JS st

> I don't think you've chosen a good example. This comment makes zero sense. Here's the part that you quoted from the OP in this thread: >> For example, JS strings are superficially similar to an array of characters, but their semantics such as equality are completely different because strings happen to be primitives while arrays are not. [emphasis added] Here's your response: > How do the semantics change? They are arrays, they literally have pointers to their characters. [emphasis added] My example provides an answer to your question, precisely as it relates to the statement you quoted. How is that possibly a bad example when it answers your exact question?

epolanski 4y ago
Because JS strings are obviously arrays (or if you prefer lists) of characters. > The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. Everytime the computer has to compare two strings it will have to compare the length and check whether each character is identical. The fact that a choice was made to make strings immutable or how to implement comparison for arrays doesn't take away from strings being arrays of 16bit chars.
- tuukkah 4y ago
  My bad, I shouldn't have said the semantics are completely different. I suppose I meant to say the semantics are defined separately. I also should have clarified that I talked of JS arrays and not the general concept of arrays or lists.
  - Jtsummers 4y ago
    It was pretty clear you were comparing JS strings and JS arrays to everyone else. They just seem to want to argue.
- jholman 4y ago
  As far as I can tell, reading the spec, you're totally wrong. Specifically, I believe that it is not true that every time the computer compares two strings that it needs to compare length. Whether or not any string or strings is/are "interned" is completely implementation-dependant. To elaborate, you could make a compliant EcmaScript interpreter wherein ALL strings, as they are constructed, are compared (presumably by hashing) against a global list of all already-constructed strings, and if the new string already existed, the in-memory representation of the string is a reference to the One True Instance of that string, such that equality comparison can always done by reference equality. Every string construction is slow, and every string comparison is constant time. Would this be smart, no. But it is consistent with the semantics that the ES spec puts on strings, which is that they are not arrays, they are primitive immutable sequences of codepoints. You could also, as you perhaps are suggesting in your first parenthetical aside, implement a compliant ES interpreter where the characters of a string are not stored in contiguous memory, being perhaps stored in some kind of complicated tree or linked lits or something. I cannot see any upside to that one. Well, I guess on very particular types of data you could save a lot of space, but wow that would be atypical. More broadly, and more of a subjective opinion, I think you're completely making the case of the top-level commenter. If someone comes into a language assuming that they know which values are values and which are references, they're going to make a lot of errors. They're going to misunderstand what equality checking does, they're going to unnecessarily make defensive copies of immutable values to avoid aliasing problems, they're going to try to mutate things, etc.

epolanski 4y ago

Because JS strings are obviously arrays (or if you prefer lists) of characters. > The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. Everytime the computer has to compare two strings it will have to compare the length and check whether each character is identical. The fact that a choice was made to make strings immutable or how to implement comparison for arrays doesn't take away from strings being arrays of 16bit chars.

tuukkah 4y ago
My bad, I shouldn't have said the semantics are completely different. I suppose I meant to say the semantics are defined separately. I also should have clarified that I talked of JS arrays and not the general concept of arrays or lists.
- Jtsummers 4y ago
  It was pretty clear you were comparing JS strings and JS arrays to everyone else. They just seem to want to argue.
jholman 4y ago
As far as I can tell, reading the spec, you're totally wrong. Specifically, I believe that it is not true that every time the computer compares two strings that it needs to compare length. Whether or not any string or strings is/are "interned" is completely implementation-dependant. To elaborate, you could make a compliant EcmaScript interpreter wherein ALL strings, as they are constructed, are compared (presumably by hashing) against a global list of all already-constructed strings, and if the new string already existed, the in-memory representation of the string is a reference to the One True Instance of that string, such that equality comparison can always done by reference equality. Every string construction is slow, and every string comparison is constant time. Would this be smart, no. But it is consistent with the semantics that the ES spec puts on strings, which is that they are not arrays, they are primitive immutable sequences of codepoints. You could also, as you perhaps are suggesting in your first parenthetical aside, implement a compliant ES interpreter where the characters of a string are not stored in contiguous memory, being perhaps stored in some kind of complicated tree or linked lits or something. I cannot see any upside to that one. Well, I guess on very particular types of data you could save a lot of space, but wow that would be atypical. More broadly, and more of a subjective opinion, I think you're completely making the case of the top-level commenter. If someone comes into a language assuming that they know which values are values and which are references, they're going to make a lot of errors. They're going to misunderstand what equality checking does, they're going to unnecessarily make defensive copies of immutable values to avoid aliasing problems, they're going to try to mutate things, etc.