Regularize the terminology for records, tuples and primitives

[littledan]

• [ x ] My issue is not bikeshedding. (we can bikeshed at
  a later proposal stage)
• [ x ] My issue is not a request to add lots of stuff to
  the semantics. (we can add things in follow-on proposals)
• [ ? ] My issue is appropriate for a stage 0 proposal and not too
  in-the-weeds.

Right now, the proposal uses words like "const", "immutable" and "value types", without really defining them. These are sort of historical artifacts of previous drafts based around other words. One important thing is that deeply frozen objects don't have this property, whatever we call it.

I want to suggest that we try to minimize how much new jargon we coin, and instead talk about "records", "tuples" and "primitives". E.g., "Records can only contain records, tuples and primitives". "Records and tuples do not have identity, and instead have equality defined by deep comparison of their contents" etc. Let's avoid using other words, as they are likely to add confusion.

If we do want to introduce a term, let's choose one of the three (probably "value types"), and define it explicitly before using it.

[kleinfreund]

Both “record” and “tuple” are new terms in the JavaScript world. They were chosen somewhat arbitrarily, and don’t convey at all what the nature of this proposal is: Introducing a new kind of data structure to JavaScript that, on the surface, behave like the known collection type structures with the speciality that their contents cannot be changed.

By avoiding the terms “constant” and/or “immutable”, this becomes even more abstract and hard to see.

[ljharb]

Both of those terms already have multiple competing meanings in JS, however, so i agree with the OP that these changes would make things clearer.

[littledan]

Yes, Record and Tuple are big new words we're introducing. So we will be defining these new, strong concepts. I just want to suggest that we minimize the number of words and concepts we introduce. If we want to use "immutable", then maybe we could use that consistently instead, like "ImmutableArray" and "ImmutableObject", though these terms have other issues. I think @BrendanEich made a good suggestion in 2011 to call these records and tuples.

[ljharb]

Indeed, "immutable" could mean any of:

• "like a primitive" (you can set properties on them in sloppy mode, but they're discarded)
• "like a shallow frozen object" (but its [[Prototype]] is mutable)
• "like a deeply frozen object"
• "like a deeply frozen object with internal slots or private fields that can't be modified" (which excludes regexes, promises, maps, sets, or Proxies which may not accurately react like this kind of object intuitively should)
• "like a nonwritable property"
• "like a nonwritable nonconfigurable property"
• "like a const variable"

[chicoxyzzy]

If we do want to introduce a term, let's choose one of the three (probably "value types"), and define it explicitly before using it.

In that case we have to make sure that "value types" term from this proposal doesn't conflict with Typed Objects' value types

[littledan]

@chicoxyzzy The use of the same term "value types" between these proposals is deliberate. The idea is that the records and tuples in this proposal would somehow form some of the basic precedents to define user-defined value types.

[littledan]

I'd suggest that we call this "proposal-records-and-tuples", along the lines of this issue.

[rricard]

Terminology should be good now