On Oct 16, 2019, at 22:13, Kyle Stanley
Maybe borrowing a word from a different language—record or datatype or something—would avoid that problem?
Hmm, I don't think "record" would work. The terms "record", "struct", and "tuple" are far too synonymous with one another (https://en.wikipedia.org/wiki/Record_(computer_science)).
Typically there’s a distinction between a record and a tuple—in fact, two distinctions. A tuple or product type is just the product of the types of its fields. All tuples of a str and an int are the same type, (str, int). Even if you give that type multiple names. For example, if you define file=(str, int) to represent a path and an fd and later define person=(str, int) to represent a name and age, file and person are the same type. A record type or datatype is a distinct type from all other types, even if they happen to have the same field types. A file(fd: int, path: str) is not the same type as a person(age: int, name: str). Sometimes field names are optional (and a record type with field names is a “proper” record type). From a quick scan of the Wikipedia article you linked, it appears to agree with this:
A record type is a data type that describes such values and variables. Most modern computer languages allow the programmer to define new record types. The definition includes specifying the data type of each field and an identifier (name or label) by which it can be accessed. In type theory, product types (with no field names) are generally preferred due to their simplicity, but proper record types are studied in languages such as System F-sub.
I’m sure there’s at least one exception that uses “record” to mean a plain product type, but I don’t think any major languages do. So I don’t think there’s any danger of people expecting Record to include tuples based on analogy with other languages, or type-theory definition, or anything else.
Perhaps something like "associative container" might be more viable? This would apply to any type that could be directly converted to or represented as a dictionary.
Surely it’s dict itself (along with third-party things like sorteddict types) that’s the associative container. That’s how C++ and other languages use the term. And if you look up “associative container” on Wikipedia, it redirects to “associative array”, which is the abstract data type of things like dict. It has nothing to do with records, except in a few languages like JavaScript that merge OO objects and dictionaries into the same thing. Also, what exactly does “could be directly converted to or represented as a dictionary” mean? A namedtuple isn’t stored or represented as a dictionary, and the only way to convert it to a dictionary is by building a dictionary on the fly out of zipping the field names with the values. That’s if anything less direct than a normal class, where you just have to access the instance’s __dict__. Finally, why are we even bikeshedding this? As Steven already explained, there’s no point in trying to nail down details for something when it’s not even remotely clear what it’s meant to be, or even could be, used for.