Quoting Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>:

> >>>>> "Marc" == Marc Feeley <xxxxxx@iro.umontreal.ca> writes:
>
> Marc> By calling it a "table" and providing table creation parameters
> Marc> that allow the user to select the implementation [...]
>
> Minor question: I'm probably missing something, but how does your
> MAKE-TABLE allow the user to select the implementation?

My proposal leaves the possibility of choosing the implementation of
the table, but it does not specify how this is done.  That would be
for another SRFI to specify (as for most SRFIs I think it is best to
keep the specification small and favour layering of SRFIs).

Here's one way of choosing between a hash table implementation
and a search tree implementation that is compatible with my make-table
proposal.

1) You get a hash table implementation by default (if no options
   other than weak-keys, weak-values, size, and init are
   present).

2) You get a hash table implementation when the hash procedure,
   the test procedure, the min-load, or the max-load parameters
   are present.

3) When a 3 way "compare" procedure (see SRFI-67) is specified then
   a search tree implementation is used.  It is an error to specify
   both a compare procedure and one or more of the hash table
   implementation parameters.  An additional "tree" parameter could
   be added to choose between different types of search trees.

Alternatively, you could have several table constructors
(make-hash-table, make-search-tree-table, etc) with their own set of
parameters, but still keep a single set of generic operators
(table-ref, table-set!, etc) for all these implementations.  Even in
this scenario, the constructors will probably have several parameters
and it is interesting to leave the possibility of future extension of
the interface, so named optional parameters should be used, which is
the point I'm trying to make.

Marc

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/