Friends,<div><br></div><div><div>I wrote a little package for "fash hash tables", which provide an</div><div>abstraction that is analogous to that of Common Lisp hash tables, but</div><div>is faster for tables with few elements, and only slightly inferior for</div>

<div>tables with many elements.</div><div><br></div><div>I did this because performance analysis showed that our system was</div><div>spending too much time in hash table operations, and using the new</div><div>package helped.</div>

<div><br></div><div>I have recently been cleaning this up, one reason being that I'd like</div><div>to open source it.  The function names used to be things like getfhash</div><div>and mapfhash.  Now they are like fhash:get and fhash:map-elements and</div>

<div>so on.</div><div><br></div><div>However, before I open-source it, I was to make sure it's "right".  It</div><div>recently occurred to me that the package name "fhash" has problems.</div><div>
<br>
</div><div>Here are pros and cons of changing it that I can see.</div><div><br></div><div>Pro: I's not a hash table in the small-cardinality case; it's a linear</div><div>lookup.  So the name is not actually accurate.</div>

<div><br></div><div>Pro: Calling such a data structure a "hash table", even as Common Lisp</div><div>does, is an abstraction violation.  Whether it works by hashing is an</div><div>implementation detail.  The Java collection library calls this a Map.</div>

<div>Python calls it a dictionary.  Clojure calls it a map.  Those are both</div><div>better names.</div><div><br></div><div>Con: Common Lisp already uses the name "hash table", so it would be</div><div>easier for existing Common Lisp programmers to see the analogy.</div>

<div><br></div><div>Advice?  Thanks!</div><div><br></div><div>Thanks!</div><div><br></div><div>-- Dan</div></div><div><br></div>