Are make-hash-table-maker etc normative?
Per Bothner
(16 Oct 2005 20:17 UTC)
|
Re: Are make-hash-table-maker etc normative? Panu Kalliokoski (17 Oct 2005 13:36 UTC)
|
Re: Are make-hash-table-maker etc normative? Panu Kalliokoski 17 Oct 2005 13:36 UTC
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/