On Sun, Oct 16, 2005 at 01:17:43PM -0700, Per Bothner wrote:
> The reference implementation contains these functions:
[...]
> They're not mentioned in the specification. Is this a bug in the
> specification or the implementation (i.e. they shouldn't be there)?
The specification is authoritative. The implementation contains many
items not required by the specification, such as vector-hash, everything
beginning with a percent sign (about a dozen names),
hash-table-association-function, hash-table-entries,
hash-table-set-entries!, appropriate-hash-function-for, and the
shorthand functions you mention.
Some of these are used to implement the functions that _are_ dictated by
the specification. However, some of these could be purged by writing
the implementation in a less elegant way. The ones you mention are not
needed, directly or indirectly, to fulfill the specification. I guess
this is why you chose these as examples of "bugs" in the implementation.
However, I feel that the role of the implementation in SRFIs is somewhat
unclear. In no way will I accept that the role of the implementation
would be to reflect the specification as precisely as possible and
nothing more. The implementation is a proof of concept that the
specification can be met; an aid for Scheme implementors to add support
for the SRFI in their systems; and an example for other Scheme authors
as to how to write code.
> I also assume that the hashing function implementations are not
> normative. Specifially, in a Java environment it makes sense to
> use the standard hashCode methods.
Of course. The implementation is not normative at all. This is
explained, I think, by the SRFI rules. An implementation is inherently
overspecified; other things in the implementation that are not normative
include e.g.:
- the default bound of the hash functions;
- use of the linear congruential method for producing hash values;
- compositionality of hash values (for instance, dependence of the hash
value of #(345 543) on the hash values of 345 and 543);
- the internal representation of hash tables;
- the dependence on SRFI-9;
- using chained hash tables instead of flat ones;
- extra argument(s) to make-hash-table;
- shortcomings of hash WRT the type of its argument;
- for which equivalence functions exactly "optimal" hash functions will
be picked (as well as what is considered an "optimal" hash function);
- and many, many more details...
I think most of this should go without saying, as it indeed has in other
SRFI's. It's flattering to gather such precise attention, though...
Panu
--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@helsinki.fi, +35850 3678003
homepage: http://sange.fi/~atehwa/
Edustajistovaalit ovat 1.11. ja 2.11. Käy http://edustajistovaalit.fi/