Issue: HASH-TABLE-ACCESS (version 2)

[Jon L White <jonl@lucid.com>]

I still would like to see SETF enabled for:

    HASH-TABLE-REHASH-SIZE
    HASH-TABLE-REHASH-THRESHOLD

At issue is the rate of "rehashing" between successive, novel entries
into the table, and the rate of consing to maintain the table.  [Perhaps 
this would be clearer if there were a function in the language called 
REHASH; Lucid 3.0 has such a function, and Interlisp-D had such a function.]

Of course, the setf methods for these two accessors would do a good deal of 
argument and consistency checking.  So what possible harm could come from 
permitting the user to alter these parameters after initial creation?  those 
implementations that substitute alists for "hash-tables" can try to adapt to 
this view, that some kind of "rehash" step [with some determined cost] is 
done after the entry which first makes:

    (hash-table-count x)  >  (* (hash-table-size x)
                                (hash-table-rehash-threshold x))

be true [assuming a floating-point value for the threshold].  This is part 
of the whole point for having "hash tables" in the language.


-- JonL --