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

 
 

bug #22159: Concerns about hash table API

Submitted by:  Neil Jerram <ossau>
Submitted on:  Tue 29 Jan 2008 10:38:25 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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.

Thanks,
Ludovic.

Ludovic Court├Ęs <civodul>
Project 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>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup