Re: Scheme style auto-resizing hashtable (fwd)

[Jay Glascoe <jglascoe@jay.giss.nasa.gov>]

On 2 Nov 1998, Harvey J. Stein wrote:

> Jay Glascoe <jglascoe@jay.giss.nasa.gov> writes:
> 
>  > constructors:
>  > 
>  > 	make-dictionary
>  > 	make-dictionaryv
>  > 	make-dictionaryq
> 
> These are for eq? eqv? & equal??  Why not the equivalent of:
> 
<snip>

yes, they use equal?, eqv?, and eq? respectively (and appropriate hashing
functions: my-hasher, my-hasherv, my-hasherq).

<unsnip>
> These are for eq? eqv? & equal??  Why not the equivalent of:
> 
>    (define (make-dictionary &optional (comparison #f) (hasher #f))
>...
<measure once, snip twice>

1. performance reasons: internally the 'dictionary, 'dictionaryv, and
'dictionaryq types are using scm_equal_p, scm_eqv_p, and scm_eq_p.  This
is much faster than doing, e.g. 

scm_apply(user_comp, scm_listify(key,SCM_CAR(pair),SCM_UNDEFINED),SCM_EOL);

2. aesthetics: I don't want to store the user's function closures in the
header; it would be ugly.  Also, if we did, then we couldn't
"read"/"write" the dictionary to/from a file. 

I could weasle my way out of both problems by making, e.g.

(make-dictionary eq?)

return a dictionary which automatically calls scm_eq_p when needed instead
of calling scm_apply.  The header would then store one of 'eq?, 'eqv?,
'equal? inside itself. 

But... what's the point?  That's essentially what make-dictionary and
friends are doing now.


	Jay
	jglascoe@jay.giss.nasa.gov