bugGuile - Bugs: bug #22159, Concerns about hash table API


bug #22159: Concerns about hash table API

Submitter:  Neil Jerram <ossau>
Submitted:  Tue 29 Jan 2008 10:38:25 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Thu 31 Jan 2008 05:07:18 PM UTC, comment #1: 

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.


Ludovic Court├Ęs <civodul>
Group administrator
Tue 29 Jan 2008 10:38:25 PM UTC, original submission:  

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.

Neil Jerram <ossau>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by civodul (Posted a comment)
  • -email is unavailable- added by ossau (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-12ab.
    Corresponding source code