On Fri, Aug 31, 2018 at 9:11 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

SRFI 125 states that

(hash-table-update! hash-table key updater)

"is semantically equivalent to, but may be more efficient than, the following code":

(hash-table-set! hash-table key (updater (hash-table-ref hash-table key)))

It seems unnecessary difficult for an implementation to provide a more efficient implementation of the latter if the updater procedure is allowed to mutate hash-table arbitrarily.

In its abstract, SRFI 125 says: "Does not guarantee that whole-table operations work in the presence of a concurrent mutation of the whole hash table (values may be safely mutated)."

If this restriction applies to hash-table-update! as well, the problem raised above won't occur. However, with this restriction, hash-table-update! would not be strictly semantically equivalent to the combination of hash-table-set! and hash-table-ref.

What has been the intent of the SRFI authors? It is possibly a good idea to spell out such a restriction/to clarify hash-table-update! in a post-finalization note.

The obvious optimization is if the implementation knows `updater' doesn't mutate the hash-table, e.g. if it is inlined.

Alternately you don't need to detect arbitrary mutations but merely rehashes, which is already tracked in some implementations, a cheap optimistic optimization.

The optimization doesn't always have to be applicable to note that it "may" be more efficient.

Specifying the same restriction as for whole-table operations may have been a good idea in retrospect, but I think this is too much for an errata.

Alex

-- Marc

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=HMSJedTgWFrXaSU4l6a5mA0U4NgC8sBK