On Tue, Jun 14, 2011 at 9:37 AM, Marco Antoniotti
<
antoniotti.marco@disco.unimib.it> wrote:
>
> On Jun 13, 2011, at 21:18 , Daniel Weinreb wrote:
>
>> Friends,
>>
>> I wrote a little package for "fash hash tables", which provide an
>> abstraction that is analogous to that of Common Lisp hash tables, but
>> is faster for tables with few elements, and only slightly inferior for
>> tables with many elements.
>>
>> I did this because performance analysis showed that our system was
>> spending too much time in hash table operations, and using the new
>> package helped.
>>
>> I have recently been cleaning this up, one reason being that I'd like
>> to open source it. The function names used to be things like getfhash
>> and mapfhash. Now they are like fhash:get and fhash:map-elements and
>> so on.
>>
>> However, before I open-source it, I was to make sure it's "right". It
>> recently occurred to me that the package name "fhash" has problems.
>>
>> Here are pros and cons of changing it that I can see.
>>
>> Pro: I's not a hash table in the small-cardinality case; it's a linear
>> lookup. So the name is not actually accurate.
>>
>> Pro: Calling such a data structure a "hash table", even as Common Lisp
>> does, is an abstraction violation. Whether it works by hashing is an
>> implementation detail. The Java collection library calls this a Map.
>> Python calls it a dictionary. Clojure calls it a map. Those are both
>> better names.
>
> Actually, in Java the naming reflects the separation between abstraction and implementation. AFAIU, clojure does not quite do this and neither does Python.
>
> I would advocate settling down on a Java-esque nomenclature with MAP or DICTIONARY as "names" for the abstraction and with different names for the implementations; e.g., DICTIONARY-TREE, DICTIONARY-FHASH, DICTIONARY-HASH-TABLE, you name it....