Editorial: "sequence of code units" != "String" ?

[jmdyck]

The spec defines SV, TV, and TRV to return a sequence of code units. But a String value is a sequence of code units. So why not define SV, TV, and TRV to return a String value?

Note that TemplateStrings appears to assume that TV and TRV do indeed return Strings. E.g., it says

Let _string_ be the TV of |TemplateMiddle|.

and not

Let _string_ be the String value whose code units are the TV of |TemplateMiddle|.

[allenwb]

The intent was to distinguish between abstract sequences of code units and actual string values which are ECMAScript language runtime values. You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.

From that perspective, the direct use of TV sequences as string values like shown above is a spec. bug. The fix would be language like that shown as the alternative.

[allenwb]

The intent was to distinguish between abstract sequences of code units and actual string values which are ECMAScript language runtime values. You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.

From that perspective, the direct use of TV sequences as string values like shown above is a spec. bug. The fix would be language like that shown as the alternative.

[jmdyck]

You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.

(Presumably you mean "You shouldn't".) That seems like a plausible reason, except:

• The "abstract sequence of code units" approach is confined to the definitions of SV, TV, and TRV. Elsewhere, those sequences are 'converted' into String values, and those values are used to validate static semantic rules. E.g., StringValue performs such a conversion, and returns a String value, and it is used in Early Error rules and in other Static Semantics operations. So keeping ES Strings out of SV/TV/TRV doesn't keep them out of static semantics.
• What's the problem with having "the full semantics" of ES Strings available at 'static' time? Presumably there's no normative effect. I.e., if SV/TV/TRV were defined in terms of Strings, implementations wouldn't be required to do anything differently. Do you think it would mislead implementers into doing something incorrect or inefficient? Do you think it would be harder to understand? (I'm doubtful on both counts.)
• How are the semantics of ES Strings any different from the semantics of sequences of code units? It's just different terminology for the same (or isomorphic) data models. How is the distinction helpful?

[jmdyck]

You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.

(Presumably you mean "You shouldn't".) That seems like a plausible reason, except:

• The "abstract sequence of code units" approach is confined to the definitions of SV, TV, and TRV. Elsewhere, those sequences are 'converted' into String values, and those values are used to validate static semantic rules. E.g., StringValue performs such a conversion, and returns a String value, and it is used in Early Error rules and in other Static Semantics operations. So keeping ES Strings out of SV/TV/TRV doesn't keep them out of static semantics.
• What's the problem with having "the full semantics" of ES Strings available at 'static' time? Presumably there's no normative effect. I.e., if SV/TV/TRV were defined in terms of Strings, implementations wouldn't be required to do anything differently. Do you think it would mislead implementers into doing something incorrect or inefficient? Do you think it would be harder to understand? (I'm doubtful on both counts.)
• How are the semantics of ES Strings any different from the semantics of sequences of code units? It's just different terminology for the same (or isomorphic) data models. How is the distinction helpful?

[bterlson]

I am also curious, it seems fine to me to just always use string values (as long as it's clear that implementations don't need to use actual JS strings, which I think it is, given the existing loosyness @jmdyck points out).

[bterlson]

I am also curious, it seems fine to me to just always use string values (as long as it's clear that implementations don't need to use actual JS strings, which I think it is, given the existing loosyness @jmdyck points out).