The proposal specifies that the table creation parameters are
positional optional parameters. Using named optional parameters
would be better, because
1) It wouldn't force the user to specify some parameters whose
default value is appropriate (for example if you want to
specify the sizehint, you are forced to specify the comparison
and hash procedures).
2) It is reasonable to expect Scheme implementations, and future
SRFIs, to extend the functionality of tables in a way that
is compatible with SRFI-69. For example the ability to
specify whether the keys and values are held weakly,
the ability to specify table load limits for resizing the
table automatically, and the ability to choose between
different table implementations (trees, lists, hash
tables, ...).
Some implementations of Scheme (Gambit, Bigloo, Kawa, Jade/DSSSL)
support named optional parameters natively (often called keyword
parameters). For example, in Gambit you could create a
table like this:
(make-table 'test: eq? 'weak-keys: #t 'size: 100)
or like this (possible because keywords are self-evaluating):
(make-table test: eq? weak-keys: #t size: 100)
I suggest that you use the first form (i.e. quoted keywords)
which is both compatible with the implementations of Scheme
that support named optional parameters natively, and also
R5RS implementations of Scheme that will have to loop over
a rest parameter list to extract the various table creation
parameters.
For your information, here are the optional named parameters
supported by Gambit's make-table and list->table:
size Exact nonnegative integer indicating the expected number
of
key/value bindings in the table (this information is
purely
advisory and can be ignored by the implementation).
init Value that will be returned by table-ref if the key is
not bound and the default value is not specified. When
init
is not specified when a table is created, then if the key
is
not bound and the default value is not specified then
table-ref will raise an exception.
weak-keys Boolean indicating if the keys are held weakly. The
system (i.e. garbage collector) may remove key/value
bindings when weak-keys is true and the key is only
reachable from the roots through weak references.
The default is weak-keys = #f.
weak-values Boolean indicating if the values are held weakly. The
system may remove key/value bindings when weak-values
is true and the value is only reachable from the roots
through weak references. The default is weak-values = #f.
test Dyadic procedure for comparing keys for equality.
The default value of test is the equal? procedure.
Any test procedure may be used, but it is expected that
the implementation will treat these cases efficiently:
eq?
eqv?
equal?
string=?
string-ci=?
hash Unary procedure mapping keys found in the table to
exact integers. The hash procedure must be consistent
with the test procedure, that is for any keys K1 and K2
(test K1 K2) implies (= (hash K1) (hash K2))
The default hash procedure depends on the test procedure.
It is expected that the implementation will provide
efficient hash procedures for the following test
procedures:
eq?
eqv?
equal?
string=?
string-ci=?
For other test procedures the implementation may
use a procedure that always returns the same value
(this is consistent with any test procedure but is
inefficient).
min-load Real number between 0 and 1 indicating the minimum
acceptable load of the table (this information is purely
advisory and can be ignored by the implementation).
max-load Real number between 0 and 1 indicating the maximum
acceptable load of the table (this information is purely
advisory and can be ignored by the implementation).
Marc