John Cowan <xxxxxx@ccil.org> schrieb am So., 2. Juli 2017 um 22:20 Uhr:
There is a problem with the alist->mapping! procedure in SRFI 146.  As is normal in alists, earlier instances of a key take priority over later instances.  When generating a mapping from scratch, there is no problem: if the association is not present, insert it, and if it is present, do not insert it.

However, when mappings are already partially populated, this won't work, because an association that is present in the mapping must be overridden when the first instance of the key is found, but not when later instances are found.  So either the alist has to be preprocessed to remove duplicate keys, or some internal data structure is required to keep track of which keys have already been overridden.  I think the extra time or space required for these actions would surprise the user.

The specifications says "Associations in the mapping and those earlier in the list take precedence over those that come later." 

So the semantics is that associations in the mapping prevail those with the same key in the alist. This is easy to implement by calling mapping-search! repeatedly.


This is why there is no alist->hash-table! procedure in SRFI 125.  I think the Right Thing is either to remove the procedure altogether, or to shift it to the group that is only supported in (srfi 146) and not in (srfi 146 hash). 

We have list->set! in SRFI 113 (which also permits a hash-table based implementation). The alist->mapping! should mirror this procedure. 

--

Marc
 

-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable