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