This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
Re the dictionary API issue, I don't have enough experience in generic dictionary handling to judge the practicality of srfi-44 in this regard. On the dictionary API issue, I understand that what Scott is opposing to is to include "efficiency" dictionary APIs to this srfi, but he agrees the practicality of such APIs and want them to be covered by subsequent concrete srfi, right? And Bradd's and Bear's concern is that if srfi-44 is released without consideration of practical implementation issues, people will start implementing certain common dictionary operations on top of srfi-44 in inefficient way, or just give up srfi-44 and doing their own API. The ideal resolution, seems to me, to have two srfis submitted together, one for a generic collection srfi and the other for a dictionary srfi. The former just mention a dictionary obeys generic collection attributes, but leaves the concrete API and implementation to the latter. Srfi-34 is referred in this discussion as a sort of "abstract" srfi that left some concrete parts to srfi-35 and srfi-36. As far as I remember, however, those three srfis are submitted altogether (I think it was initially one srfi, then splitted to three). Doing that made people easy to understand how abstract description related to concrete implementation. I'd feel comfortable if two srfis come together. --shiro