5 ms·

If these operations produce mutable strings, the conditions under which that would be allowed are fairly stringent. It's not worth doing; it's better for the Li

If these operations produce mutable strings, the conditions under which that would be allowed are fairly stringent. It's not worth doing; it's better for the Lisp to have constructs that allow the programmer easily stage the evaluation in the desired way. Common Lisp has load-time-value. It's also easy to write a macro called macro-eval which evaluates its argument at macro time, and substitutes the result (as a quoted object).

basil-rash 2y ago
What is the case you imagine where mutable strings would prohibit this?
- kazinator 2y ago
  Any situation where the program depends on the expression producing a new string each time it is evaluated, rather than returning the same string. The program may be modifying the string, on the assumption that nothing else has access to it, since it is brand new. The program could also be relying on the string having a unique identity, not comparing equal to any previously seen object. (E.g. assuming that each time the expression is evaluated, it produces an object that can serve as a unique key in an EQ hash table). Any situation in which these behaviors cannot be ruled out (because the object escapes beyond the scope of analysis), the optimization cannot be applied.
  - basil-rash 2y ago
    Ah, well all JS strings are always immutable and only value-referable (you have no access to the underlying memory location), so that’s not a concern here.
    - kazinator 2y ago
      What about the identity side of it? Does the JS specification say that an operation like "a" + "b" is not required to create a new object? Regardless of whether there is such a spec, you can write code that is sensitive to the difference.
      - basil-rash 2y ago
        In fact, you cannot. But I encourage you to try!
        kazinator 2y ago
        It looks like JS doesn't expose equality operator which can distinguish different strings. Thus "abc" and "abc" are the same object, no matter how they are produced, even if under the hood they are separate instances.
        basil-rash 2y ago
        Pretty much, though some would contest calling strings “objects”. The spec indeed goes through some trouble to ensure they are pure value-types and do not exhibit any reference-like semantics, for instance by prohibiting their use as keys of WeakMaps and WeakSets - along with numbers, booleans, nullish values, and bignums.
        deleted 2y ago
        [deleted]
        kazinator 2y ago
        [flagged]
        basil-rash 2y ago
        In the context of a discussion on JS, the spec assigns a very specific meaning to the term “object”, one which value-types do not satisfy. That is, indeed, the entire point of this thread, and to suddenly switch terminology then ramble about how you’re better than “script kiddies” screams rhetorical incompetence. It's clear that you don’t know JS. I was trying to help you understand one interesting design decision they make, but you’ve taken to personal attacks against the entire community in a way that I don’t find worth humoring. Good day.

basil-rash 2y ago

What is the case you imagine where mutable strings would prohibit this?

kazinator 2y ago
Any situation where the program depends on the expression producing a new string each time it is evaluated, rather than returning the same string. The program may be modifying the string, on the assumption that nothing else has access to it, since it is brand new. The program could also be relying on the string having a unique identity, not comparing equal to any previously seen object. (E.g. assuming that each time the expression is evaluated, it produces an object that can serve as a unique key in an EQ hash table). Any situation in which these behaviors cannot be ruled out (because the object escapes beyond the scope of analysis), the optimization cannot be applied.
- basil-rash 2y ago
  Ah, well all JS strings are always immutable and only value-referable (you have no access to the underlying memory location), so that’s not a concern here.
  - kazinator 2y ago
    What about the identity side of it? Does the JS specification say that an operation like "a" + "b" is not required to create a new object? Regardless of whether there is such a spec, you can write code that is sensitive to the difference.
    - basil-rash 2y ago
      In fact, you cannot. But I encourage you to try!
      - kazinator 2y ago
        It looks like JS doesn't expose equality operator which can distinguish different strings. Thus "abc" and "abc" are the same object, no matter how they are produced, even if under the hood they are separate instances.
        basil-rash 2y ago
        Pretty much, though some would contest calling strings “objects”. The spec indeed goes through some trouble to ensure they are pure value-types and do not exhibit any reference-like semantics, for instance by prohibiting their use as keys of WeakMaps and WeakSets - along with numbers, booleans, nullish values, and bignums.
        deleted 2y ago
        [deleted]
        kazinator 2y ago
        [flagged]
        basil-rash 2y ago
        In the context of a discussion on JS, the spec assigns a very specific meaning to the term “object”, one which value-types do not satisfy. That is, indeed, the entire point of this thread, and to suddenly switch terminology then ramble about how you’re better than “script kiddies” screams rhetorical incompetence. It's clear that you don’t know JS. I was trying to help you understand one interesting design decision they make, but you’ve taken to personal attacks against the entire community in a way that I don’t find worth humoring. Good day.