On 2023-11-18T00:32:28+0100 (Saturday), Daphne Preston-Kendal writes:
> On 18 Nov 2023, at 00:14, Shawn Wagner <xxxxxx@gmail.com> wrote:
>
> > I'm throwing together an implementation of this for Racket, and ran
> > into the first of probably many questions:
> >
> > The description of hash-table-set! says "Whenever there is a
> > previous association for a key, it is deleted". Does that mean the
> > key gets moved to the end of the insertion order list from wherever
> > it was as if it was deleted and re-inserted in two steps, instead of
> > just updating the value of the existing entry and leaving the order
> > unchanged?
>
> For what it’s worth, my implementation does the latter.
>
> I think this is also the sensible thing to do. It’s familiar to
> programmers (it’s what Python and Ruby’s ordered hash tables do, at
> least), and it avoids creating a dead hash table entry for no real
> reason. (Or in a doubly-linked-list based implementation, it avoids
> doing pointer manipulation for no reason.)

Very late to the party here, but I thought I'd add a data point: Java's
LinkedHashMap also preserves the original position on a
re-insertion/update.  Quoting from it's Javadoc [1]:

  "Note that encounter order is not affected if a key is re-inserted
  into the map with the put method. (A key k is reinserted into a map m
  if m.put(k, v) is invoked when m.containsKey(k) would return true
  immediately prior to the invocation.)"

> This spec language is taken over from SRFI 125 where the point was
> moot; it should be clarified.

I agree. A reasonable distinction could be made between the cases of
inserting a new key and updating the value of a key that's already
present in the hash table.

[1] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/LinkedHashMap.html

Regards,

-chaw