4 ms·

It seems odd that we haven't standardized on a name for maps/tables/dictionaries/associative-arrays/hashes.

shadowfiend 13y ago
Well, hashes in particular implies a very specific kind of map/table (one that uses hashing). I think the most common non-implementation-dependent names are maps, dict(ionarie)s, tables, and associative arrays.
- logicallee 13y ago
  the reason it's in OP's list is that that's just what Perl calls associative arrays. (http://en.wikibooks.org/wiki/Perl_Programming/Hash_Variables http://en.wikibooks.org/wiki/Perl_Programming/Hash_Variables) Hence it's literally the exact same thing as a dictionary, but is named a hash in Perl.
  - judk 13y ago
    Hah, in the second paragraph the author forgot, called it "associative array", and then remembered "hash" for the latter half of the sentence.
kevinmchugh 13y ago
And in JS, it's an object. Figuring out how to store arbitrary key-value pairs should be one of the first steps in learning a new language, given that every language has a different name for it. Associative Array is probably my least favorite name for it, since it implies arrays aren't associative. It was a clojure book that first made me realize an array is a map that only allows ints for keys.
- Skinney 13y ago
  Actually an object in JS stores string keys only, if you try to insert something else it's auto-converted to strings. Array is an object wich stores integer keys. You don't really have a datastructure that stores arbitrary keys in JS (when not including third party libraries). This will be changed with Ecmascript Harmony though (dedicated Map type)
- kilon 13y ago
  Its also an object in Python , Pharo and most likely Ruby too.
  - masklinn 13y ago
    He meant that — before ES6 anyway — javascript's "associative array" are objects. As in, they're the basic objects of the languages, generally instances of Object: > {}.__proto__ === Object.prototype true although nowadays you can use `Object.create(null)` to get a bare object, with no prototype: > Object.create(null).__proto__ null
- banachtarski 13y ago
  Well, there is the distinction between a sparse array and a contiguous one, both of which are technically associative. I associate the former with the term "associative array" though.
- jaredsohn 13y ago
  > an array is a map that only allows ints for keys Actually, it only allows nonnegative ints for keys. Also, it has the added undesirable property of requiring memory proportional to the largest key value, rather than number of keys.
  - justincormack 13y ago
    Not if it is Fortran.
colanderman 13y ago
Well, most of those really conflate two things: static heterogeneous "maps", and dynamic homogeneous maps. The former being a structure whose keys are known at compile time (static) and whose values may be of different types (heterogeneous); the latter being a structure whose keys are not known until run time (dynamic) and whose values must all be of the same type (homogeneous). Most languages conflate these, because they kind of look the same, but they are entirely different use cases, with different use patterns, permit different optimizations, and their generalization (a dynamic heterogenous structure) is pretty useless. The relational model [1], which has been around since 1969, does distinguish these. The static heterogeneous structure is called a "tuple", and the dynamic homogeneous structure is called a "relation". If only language designers would stop conflating the implementation of these structures with how they are used, we could drop the cringeworthy names "associative array" and "hash", stop calling tuples "maps" (which is a specific kind of relation), and stop calling relations "tables" (which are two-dimensional arrays, which are another kind of relation). Erlang at least as of R17 has mostly kept this distinction (Erlang maps mostly support the static heterogeneous use case). However the majority of users are keen to jump on the "maps" bandwagon as a way to get syntax support for dynamic homogeneous use (which makes utterly no sense to me, as most of the syntax is for pattern matching and construction, which makes little sense in the dynamic case!). I am glad R17 does not include many of the proposals for such syntax that I've seen on the mailing list; and instead sticks closely to the original static heterogeneous design proposed by Richard O'Keefe. [1] http://en.wikipedia.org/wiki/Relational_model http://en.wikipedia.org/wiki/Relational_model
- Morgawr 13y ago
  I agree with what you said but I don't see how a heterogeneous dynamic structure is "pretty useless" though
  - colanderman 13y ago
    In a dynamic structure, you're adding and removing key/value pairs at runtime, when you generally don't know what the keys are. When you later access the structure, since you don't generally know what's in it, you can't know the type of any of the values, and hence you can't know what operations are valid on them. The way around this of course is to tag the values with their type. This is usually done implicitly in dynamically typed languages (e.g. Javascript), and always must be done explicitly in statically typed languages (e.g. OCaml). But once you do that, you have a single type for all the things in the structure (a tagged union type) and it's now a homogeneous structure. Either that, or you can split your mapping into multiple mappings, one for each type of thing. That has the benefit of permitting better optimization (you don't need to store per-value tags, among other benefits). (Even in dynamically typed languages, it's better to explicitly tag things anyway. If you have a structure that can legitimately contain two kinds of things, one which happens to be an integer, and one which happens to be a string, then it's pretty likely it might later need to contain a third kind of string, which, if it happens to be an integer or a string, well, you're screwed.)

Well, hashes in particular implies a very specific kind of map/table (one that uses hashing). I think the most common non-implementation-dependent names are maps, dict(ionarie)s, tables, and associative arrays.

logicallee 13y ago
the reason it's in OP's list is that that's just what Perl calls associative arrays. (http://en.wikibooks.org/wiki/Perl_Programming/Hash_Variables http://en.wikibooks.org/wiki/Perl_Programming/Hash_Variables) Hence it's literally the exact same thing as a dictionary, but is named a hash in Perl.
- judk 13y ago
  Hah, in the second paragraph the author forgot, called it "associative array", and then remembered "hash" for the latter half of the sentence.

kevinmchugh 13y ago

And in JS, it's an object. Figuring out how to store arbitrary key-value pairs should be one of the first steps in learning a new language, given that every language has a different name for it. Associative Array is probably my least favorite name for it, since it implies arrays aren't associative. It was a clojure book that first made me realize an array is a map that only allows ints for keys.

Skinney 13y ago
Actually an object in JS stores string keys only, if you try to insert something else it's auto-converted to strings. Array is an object wich stores integer keys. You don't really have a datastructure that stores arbitrary keys in JS (when not including third party libraries). This will be changed with Ecmascript Harmony though (dedicated Map type)
kilon 13y ago
Its also an object in Python , Pharo and most likely Ruby too.
- masklinn 13y ago
  He meant that — before ES6 anyway — javascript's "associative array" are objects. As in, they're the basic objects of the languages, generally instances of Object: > {}.__proto__ === Object.prototype true although nowadays you can use `Object.create(null)` to get a bare object, with no prototype: > Object.create(null).__proto__ null
banachtarski 13y ago
Well, there is the distinction between a sparse array and a contiguous one, both of which are technically associative. I associate the former with the term "associative array" though.
jaredsohn 13y ago
> an array is a map that only allows ints for keys Actually, it only allows nonnegative ints for keys. Also, it has the added undesirable property of requiring memory proportional to the largest key value, rather than number of keys.
- justincormack 13y ago
  Not if it is Fortran.

colanderman 13y ago

Well, most of those really conflate two things: static heterogeneous "maps", and dynamic homogeneous maps. The former being a structure whose keys are known at compile time (static) and whose values may be of different types (heterogeneous); the latter being a structure whose keys are not known until run time (dynamic) and whose values must all be of the same type (homogeneous). Most languages conflate these, because they kind of look the same, but they are entirely different use cases, with different use patterns, permit different optimizations, and their generalization (a dynamic heterogenous structure) is pretty useless. The relational model [1], which has been around since 1969, does distinguish these. The static heterogeneous structure is called a "tuple", and the dynamic homogeneous structure is called a "relation". If only language designers would stop conflating the implementation of these structures with how they are used, we could drop the cringeworthy names "associative array" and "hash", stop calling tuples "maps" (which is a specific kind of relation), and stop calling relations "tables" (which are two-dimensional arrays, which are another kind of relation). Erlang at least as of R17 has mostly kept this distinction (Erlang maps mostly support the static heterogeneous use case). However the majority of users are keen to jump on the "maps" bandwagon as a way to get syntax support for dynamic homogeneous use (which makes utterly no sense to me, as most of the syntax is for pattern matching and construction, which makes little sense in the dynamic case!). I am glad R17 does not include many of the proposals for such syntax that I've seen on the mailing list; and instead sticks closely to the original static heterogeneous design proposed by Richard O'Keefe. [1] http://en.wikipedia.org/wiki/Relational_model http://en.wikipedia.org/wiki/Relational_model

Morgawr 13y ago
I agree with what you said but I don't see how a heterogeneous dynamic structure is "pretty useless" though
- colanderman 13y ago
  In a dynamic structure, you're adding and removing key/value pairs at runtime, when you generally don't know what the keys are. When you later access the structure, since you don't generally know what's in it, you can't know the type of any of the values, and hence you can't know what operations are valid on them. The way around this of course is to tag the values with their type. This is usually done implicitly in dynamically typed languages (e.g. Javascript), and always must be done explicitly in statically typed languages (e.g. OCaml). But once you do that, you have a single type for all the things in the structure (a tagged union type) and it's now a homogeneous structure. Either that, or you can split your mapping into multiple mappings, one for each type of thing. That has the benefit of permitting better optimization (you don't need to store per-value tags, among other benefits). (Even in dynamically typed languages, it's better to explicitly tag things anyway. If you have a structure that can legitimately contain two kinds of things, one which happens to be an integer, and one which happens to be a string, then it's pretty likely it might later need to contain a third kind of string, which, if it happens to be an integer or a string, well, you're screwed.)