Wrong handling of duplicate keys in alist-hash-table and plist-hash-table
Christoph Arenz
tiga.arenz at web.de
Fri Apr 7 15:16:14 UTC 2017
Hi there,
apparently for association lists, it is possible to have 'new' entries
in front of the list 'shadow' old entries. See
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node153.html
However, the Alexandria function alists-hash-table does not account for
this behavior when transforming an a-list to a hash-table. There is no
checking for duplicate keys in an a-list, resulting in the 'older'
entries finding their way in the resulting hash-table.
Similar is for p-lists and the plist-hash-table function, though I found
contradicting statements whether duplicate keys are allowed for those.
At least the hyperspec explains that in case of multiple pairs, the
first key/value pair defines the property. See
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_p.htm#property_list
CL-USER> alist
((:ONE 1) (:TWO 2) (:ONE :SURPRISE))
CL-USER> (assoc :one alist)
(:ONE 1)
CL-USER> (gethash :one (alexandria:alist-hash-table alist))
(:SURPRISE)
T
Thanks for your consideration!
Kind Regards,
Christoph Arenz
More information about the alexandria-devel
mailing list