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.