Hacker News Reader

Comment by weinzierl | Hacker News Reader

"A record is an unordered collection of name to value mappings"

If there is one thing that is for sure, it is that we have too many names for "collection of name to value mappings".

In my book the term record is not what first comes to mind when thinking of unordered mappings. All of the usages of the word I can think of imply the possibility of access by name while retaining order. Sometimes this allows easy indexed access (database rows used to be called records) sometimes it doesn't (C structs which also used to be called record types).

View on HN

C structs are record types, but, while the standard does guarantees an in-memory ordering, in the general case you can't really iterate through members and always have to access by tag, so it might as well be unordered.

Also in C++:

   struct A { int x; int y; } a;
   struct B { int y; int x; } b;
   template<class C> concept has_x_y = requires(C c) {
     { c.x } -> std::convertible_to<int>; 
     { c.y } -> std::convertible_to<int>; 
    };

   int sum(has_x_y auto z) { return z.x + z.y; }
   ...
   sum(a);
   sum(b);

But for an open world model we need the unordered definition.

As two structs that have same names at different places in the struct still need to conform to the generic record type

Yes, it is a very unusual definition of a record. As you rightfully noted, typically, a record is defined as a composite data structure mixing data types (indeed something more or less equivalent to a C struct basically).

Access by name is not even truly necessary and the difference between tuples and records is minimal (you could build something looking exactly like field access on top of tuples with functions and would get as a result something indistinguishable from an actual record).

The existence or not of an order is then totally accessory and it's generally straightforward to build an order on both provided the data types they contain is orderable by ordering the field and then using a lexicographic order.

Yes in Haskell the names are just sugar for index numbers in a tuple (effectively)

I tend to agree with you. “Unordered” is very strange when clearly it is consistently “ordered” by some function(name, insertion_id) to facilitate low latency lookup.

The iteration order seems arbitrary to a human, but that is exclusively because function(name, insertion_id) is not optimized for a human. It seems strange to call the collection “unordered” because of how it appears to a human.

Unordered simply means the order isn’t exposed, not that the bits have somehow literally fallen out of the computer and are scattered on the floor.

I remember trying to explain to someone that Java's List type was ordered, where they thought ordered meant sorted. Turns out, language is tough.

This often comes up for map types. C++ std::map and Python OrderedDict are both "ordered" but in very different senses of that word. People who wanted one but got the other will most likely be unhappy. Both do always work for "golden test" inputs, which will satisfy the sort of person who writes unit tests after finishing the software by picking inputs and then mutating the checked outputs until the test passes...

Reply on news.ycombinator.com