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/