Naming

[manfreed]

Hi guys,

Nice feature, I can't wait to be able to work with native immutable data structures in the future. I'm just not sure about the terminology:

I was mostly unfamiliar with the proper meaning of records and tuples before now, so I did a little research. What I found is that they represent simpler and more generic ideas than what this proposal introduced. Also, some programming languages use these terminologies but differently than how this proposal intends to implement them.

I'd propose just to stick with "immutable objects" and "immutable arrays".

Imagine your average JS dev. Already familiar with objects and arrays, probably already familiar with immutability thanks to React. It is easier for them to grasp the meaning of an "immutable array" than a "touple", even if they are the same thing.

I don't really see a drawback of simply prefixing already known features with "immutable" to name these features. It's boring. It's a bit longer. On the other hand, we get a simple, easy-to-understand naming which then can be applied to other data structures in the future (for example immutable maps or immutable dates)

[slikts]

Tuples aren't just immutable arrays, because they have value semantics. Value semantics means that tuples are both immutable and that comparisons between tuples are structural and not referential.

[papb]

I agree with @slikts, since tuples are a special kind of immutable arrays, it is even better to have another name, preventing people from thinking they are nothing more than an immutable array

[rickbutton]

echoing the other comments, the problem with calling them "immutable objects" and "immutable arrays" is that they are not objects or arrays (which are objects), because they are primitive values and have value semantics (as @slikts has mentioned). If we called them immutable objects/arrays, I would expect them to have prototypes, identity, and all of the other properties that objects have that "values" don't (string, number, etc)

given the above, we think record and tuple describe the intent more correctly than immutable object/array, although if a compelling case is made for something other than record/tuple that don't describe them as objects, it would be worth consideration.

[dcporter]

I for one am sold on “tuple”. Is there prior art for “record” being a value type? What other names could fit the bill there?

[ljharb]

struct

[slikts]

I ended up naming them ValueObject in my tuple implementation. A record to me doesn't necessarily imply value semantics.

Python has something called "named tuples" which resembles an object, but the names of the tuple members don't affect the value of the tuple.

[mpcsh]

Is there prior art for “record” being a value type?

Many functional languages with diverse typing disciplines call these things "records". Not sure if this is counts as "prior art," but this is where I know the term from.

[rricard]

The champion group is strongly favoring the current naming. That being said, if being presented with strong arguments for another naming before stage 3, we are open to change it.

[joakim]

I'm not educated in type theory, so I had to do some research on the nomenclature. If I'm mistaken in some of this, please jump in and correct me.

Tuple is mainly described as a mathematical concept on Wikipedia. When the name is used in functional programming languages, it appears to be associated with algebraic data types, pattern matching and destructuring assignments. In this aspect, the proposal deviates from "prior art". Not that that's a bad thing!

In mathematics, a tuple is a finite ordered list (sequence) of elements.
In computer science, tuples come in many forms.

Record appears to be a good fit according to Wikipedia:

A record is a collection of fields, possibly of different data types, typically in a fixed number and sequence.

Structure and Dictionary are also used. Strictly speaking, they're Associative arrays.

What names could apply to Tuple then? Array seems to be the name that best matches this proposal's Tuple. Array is of course taken by JavaScript's dynamic arrays ([]), but it's not inaccurate to say that this proposal's Tuple is a static array.

List is the name of the abstract data type that applies to arrays. Arguably a more accurate name than tuple? Other languages that have List as an immutable array include Scala and Kotlin, while in Python it's a dynamic array, and of course a linked list in the Lisp-family.

In computer science, a list or sequence is an abstract data type that represents a countable number of ordered values, where the same value may occur more than once. An instance of a list is a computer representation of the mathematical concept of a tuple or finite sequence (…)

The name list is also used for several concrete data structures that can be used to implement abstract lists, especially linked lists and arrays.

Sequence is another mathematical concept that may be used to describe lists.

In mathematics, a sequence is an enumerated collection of objects in which repetitions are allowed and order matters.

Alternative names for Tuple:

• List
• Sequence
• StaticArray
• FixedArray

Alternative names for Record:

• Structure
• Dictionary
• StaticObject
• FixedObject

Sorry for complicating things :)

[ljharb]

Lists and sequences don’t connote fixed-length to me; Tuple does.

[joakim]

@ljharb I somewhat agree. The most accurate name is actually Array. I therefore think StaticArray and FixedArray are better alternatives. They're descriptive and don't hide the fact that they are very much related to their mutable counterparts.

[ljharb]

I don’t think that’s the most accurate name either - arrays are not universally fixed-size, even outside JavaScript.

[joakim]

I suppose you're right. Wikipedia seems to take "array" to mean static array by default, as opposed to dynamic, probably a remnant from ancient languages like C. StaticArray is bang on, if you ask me. Not as catchy as Tuple, though.

[khaosdoctor]

Reading on @joakim answer (zero expertise on type theory too, just my 2 cents), I was thinking the same thing. I don't think we should use StaticArray or FixedArray since, as it was mentioned, Tuples are inherently different at a type level. So, for tuples I'm sold for List or even {Immutable, Fixed, Frozen}List (as it's being discussed on #10 about the naming conventions using keywords).

for Records I have to say that what is worrying me most about it is the implementation on type systems like TypeScript, despite also being addressed on #9, but TS already has a Record type. So in this case I'd be leaning towards the Dictionary and its variations as well, I think it's better suited and better explained.

[rauschma]

• One issue with the current naming is that it clashes with TypeScript – especially “tuple”.
• Using “static” in this context seems confusing w.r.t. how “static” is used in the context of classes.
• “Lists” are often linked lists and feel wrong to me.

Thus, my favorite alternatives are FixedArray and FixedObject, so far.

[noppa]

Many newcomers are already surprised by typeof null being "object". I think they'll be even more surprised when they find that typeof FixedObject({}) is not.

[rricard]

Regarding the TypeScript naming clash, we do intend to find an effective way to disambiguate with the current Record & Tuple naming, we are currently working on a suggestion for that.

Our champion group has been looking at alternative naming multiple times over the past few years, unfortunately finding an alternative is hard. We found that all alternatives using "Object" or "Array" in them are difficult to pull off specifically because Record & Tuple are, by nature, not Objects or Arrays, whatever prefix we put in front of them.
We even considered prefixing Record & Tuple (ex. FixedRecord, FixedTuple), the problem is that we don't have non-prefixed variants of them in the language either so we're still taking out the possibility to name something Record or Tuple from the language because of the prefixed variant. So in the end simplicity pushes us to just name them Record and Tuple.

At this point, any new naming needs to pass a very high bar: it needs to differentiate itself from Objects and Arrays, it needs to stay short while being representative enough because by this point, a change of naming is a change of all communication around the proposal. That is fine if we find something truly more representative (but that might be based on subjective opinions), otherwise staying the course makes the most sense for us.

[rauschma]

@rricard Good points! Then TypeScript might have to change (but it’ll be painful…):

• I’d prefer the name Dictionary<K,V> for what is currently Record<K,V>, anyway.
  • It’s used a lot in code, so maybe an alias plus, optionally, deprecation of Record.
• The term “tuple” never appears in code (only in material about TypeScript and maybe error messages) and will be easier to rename. “Fixed array” then?

To my eyes, there is no good alternative to “tuple” for the proposed JavaScript feature.

“Record” and “struct” both work well, but given that Dictionary would actually be an improvement (IMO) for TypeScript, changing the current name seems less important.

[rricard]

Those are good suggestions @rauschma! They are pretty much in line with what we had in mind but I personally prefer the naming you are proposing to replace and disambiguate.

Yes, it will be painful (I do work with a lot of TS on a day to day basis and Record is used a lot!). We looked a lot (and are still looking) at possible alternatives but the more time advances the harder it gets to change naming...

[rricard]

We are going to stay with Record & Tuple as we did not find better alternatives to it and branding on the proposal is established.