Re: [MIT-Scheme-devel] specifying hash table weakness

[Chris Hanson]

In cases like these I prefer a small number of very general
definitions, so I'd favor having all the options be defined as
arguments.  Provided, of course, that there are compatibility bindings
for existing usage.

On Sat, Aug 14, 2010 at 8:12 PM, Taylor R Campbell <address@hidden> wrote:
>   Date: Sat, 14 Aug 2010 19:20:06 -0700
>   From: "Arthur A. Gleckler" <address@hidden>
>
>   > (MAKE-x-HASH-TABLE* <weakness> #!OPTIONAL <initial-size>),
>   >  x \in {EQ, EQV, EQUAL, STRING}
>
>   I wonder whether it makes sense to make X a parameter, too.  That
>   wouldn't prevent special treatment of EQ.
>
> That would require adding some more parameters, unless there is only a
> fixed set of valid arguments for x so that the appropriate values for
> the other parameters can be chosen like in SRFI 69 implementation.
> Personally I prefer encoding such limited choices in the names -- if
> you can pass a procedure, it is tempting to pass a procedure outside
> the allowed set, and the subsequent failure is confusing.
>
> We could have a procedure
>
> (MAKE-HASH-TABLE* <key=?> <key-hash> <rehash-after-gc?> <weakness> 
> <initial-size>)
>
> or something, too.
>
>   The other obvious possibility is to make a hash table constructor
>   maker, i.e. to curry the construction of hash tables, e.g.:
>
>     ((make-hash-table-constructor comparator weakness) initial-size)
>
>   That requires the addition of the fewest new identifiers.  We can
>   watch to see which combinations are actually used and then make
>   shortcut identifiers for them.
>
> This is what the proposed HASH-TABLE-CONSTRUCTOR already does, except
> that it has two more parameters, for the hash function and for whether
> the hash function is altered by garbage collection.
>
> _______________________________________________
> MIT-Scheme-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>