[bug #22159] Concerns about hash table API

[bug #22159] Concerns about hash table API

[Neil Jerram]

URL:
  <http://savannah.gnu.org/bugs/?22159>

                 Summary: Concerns about hash table API
                 Project: Guile
            Submitted by: ossau
            Submitted on: Tuesday 01/29/08 at 22:38
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Raising a bug to track the following concerns from Gregory Marton... (which
remain valid, despite the fact that some of them can be worked around them to
some extent in Scheme, or by using SRFI-69).

Moreover, I think the hash specification is problematic.
   (a) the representation seems to wish to hide the current size of the
       hash vector, or at least that would be sensible, but it is exposed
       in the printout and as an argument to the hash-function supplied to
       hashx.  The point at which the hash is resized is unpredictable from
       the user's point of view.  This is three flavors of rep exposure.

   (b) if, as the doc says, "it's imperative that just one set is then used
       consistently, or results will be unpredictable", then it makes sense
       to enforce this.  A common way to enforce it is to ask for the hash
       function just once, at creation time.  By requiring it everywhere,
       we force the user to expose a representation, the hash function and
       equality predicate, between one part of their program and another.

   (c) the assoc requirement is a rep exposure of a third sort -- it exposes
       the fact that buckets are alists.  There is no reason for the user to
       know this, and there is no reason it should be so.  If a future
       implementation wants to do something else, say hash with another
       hash, they will have to emulate assoc-ability to make this API work.
       Moreover, this forces the user to write the assoc function on top of
       their equality predicate, which is neither fast (it's Scheme instead
       of C) nor DRY (Don't Repeat Yourself -- a principle of not
       duplicating code).

If the current set of decisions seems self-consistent and useful to
the community, then I guess I'd submit an enhancement request, for a
new set of fast functions:
   (make-hashf-table one-arg-hash-function equality-predicate [size])
   (hashf-set! hashf-table 'key value)
   (hashf-ref hashf-table 'key [default])
   (hashf-remove! hashf-table 'key)
   (hashf-size hashf-table) ===> the number of keys stored
   ... [clear get-handle create-handle for-each for-each-handle map->list

"f" for the functions it stores.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22159>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #22159] Concerns about hash table API

[Ludovic Courtès]

Follow-up Comment #1, bug #22159 (project guile):

FWIW, I agree that these are all valid concerns.

However, I don't think we should add another hash-table API, since that would
be the third one.

Thanks,
Ludovic.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22159>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/