1. Are you suggesting that the lack of a syntax to hide the need for helper functions disqualifies them?

   No. I'm saying that (TTBOMK) alist & plists are lists and can only be sequentially accessed--which isn't random access, and therefore disqualifies them from being AAs. Ie. searching them is O(n) instead of O(1).

   As I also said, my Lisp knowledge is limited. Then best evidence I have for this are a couple of quotes from the Common Lisp Manual:hashtables: "Finding the value is very fast, even if there are many entries, because hashing is used; this is an important advantage of hash tables over property lists." & "adding a value to a hash table is a destructive operation; the hash table is modified. By contrast, association lists can be augmented non-destructively."

2. I read the linked post.

3. in a normal array we can meaningfully talk about the distance between elements because integer keys can be subtracted one from another. We can also divide indices (or more precisely the distance between two indices) by some constant. Those two properties play an important role in certain searching and sorting algorithms (binary search and sort for example)

   Hm. You can do math with the bucket indicies too. It won't allow you to write a binary search, but then you don't need to.

   'Arrays' & 'associative arrays' are different things. Like 'trees' and 'shoe trees'; 'salmon' and 'rock salmon'; .... See below.

4. Even if Perl is always using bucket order, isn't the net result a different key order?

   Yes. But you would also get a different data ordering if:

   • they chose a better hashing algorithm;
   • or they adjusted the re-hash threshhold;
   • or if you insert or delete a key;

     The point is that the iteration ordering doesn't change because of the hash seed randomisation. The ordering of the keys (one of a pair of data items) changes. But the iteration order has nothing to do with the ordering of the values--for either hashes or arrays. I'll attempt to make that clearer :)

     The "implicit ordering" of arrays, has nothing to do with the ordering of the values held within it. If you take the same list of data and unshift them into an array; and push them onto an array; the iteration order remains the same; but the perceived ordering of the data will be different(reversed). And if you spliced them into the 'middle', you'd percieve a different ordering when you iterated the array sequentially.

     This is no different with hashes; the buckets are iterated sequentially+. Which perceived ordering values come out in, depends on where they were put during insertion, not the the iteration ordering. And the insertion ordering is dependant upon many things: the current size of the bucket array; the number of values added; the hashing algorithm (including the seed used). Even just adding some keys and then removing them again will caused the percieved ordering of the (same) keys to change:

     undef @h{ 1 .. 8 };;
     
     print keys %h;;
     6 3 7 2 8 1 4 5
     
     undef @h{ 9 ..  16 };;
     delete $h{ $_ } for 9 .. 16;;
     
     print keys %h;;
     7 2 1 6 3 8 4 5
     [download]

     What am I misunderstanding there?

     I believe you are conflating the iteration ordering and the (resultant) data ordering. The hash seed randomisation affects which buckets the keys are placed in, not the order those buckets are iterated.

     Sure, if all else remains unchanged, the net effect of hash key randomisation might be a difference in the perceived order of the keys as output. But if all else stays equal (including the seed), and any one of those other things changes, you will get the same perception. Just as you would with an array, if a tied array decided to use a hash as it's storage mechanism.

And non-programmers won't know what either are, and might guess they are more similar than they really are. But that's really not a problem because they won't know the properties of arrays, so will have no basis for real confusion.

Telling others not to use an industry standard term, because you've reached the conclusion that it's a bad one, is ...

I don't object to your pointing out your objections to the term--I did that myself recently for undefined behaviour--and I might even agree with you. But it is one thing to raise and support one's objections to a industry standard term; it's all together a different thing to tell people off for using it.