[R6RS] Hash table terminology consistency

[Anton van Straaten]

Will wrote:
> The first paragraph says "...the equivalence predicate,
> which is a procedure that accepts two keys and returns
> #t if they are equivalent."  The two problems with that
> are that it doesn't say the equivalence predicate must
> return #f if they aren't, 

For the moment (pending any more elaborate change), I've tacked on ", 
otherwise returns #f" to the sentence in question (rev 906).  I've made 
a few other related changes; for a diff of the latest changes, you can use:

   svn diff -r 897 hashtable.tex

(I had some problems with a truncated file around rev 905 and 904, so 
diffing against them isn't useful.)

> and it doesn't allow the
> equivalence predicate to return a true value other than
> #t.  It would be better to say "...the equivalence
> predicate, which is a procedure that returns true if
> and only if they are equivalent."  (Note that "true" is
> a technical term in the R6RS, meaning any value other
> than #f; see section 9.1.)
> 
> The description of make-hash-table says the equiv?
> predicate must return a boolean.  I don't see the
> point of that restriction.  

The restriction arose mainly by extension from eq? and eqv?, as well as 
that the terms "predicate" and "equivalence predicate" were already 
being used (prior to my latest changes) in various places, including in 
the description and name of the procedure 
hash-table-equivalence-predicate.

R6RS section 9.6 defines a "predicate" as "a procedure that always 
returns a boolean value (#t or #f)."  To relax the restriction, assuming 
we don't want to relax the definition in 9.6, I assume we should use an 
alternative term to avoid inconsistency, and avoid the term "predicate" 
except in connection with eq? and eqv?.

> If we're going to restrict
> the predicate to return a boolean, then its description
> in the first paragraph should also require it to return
> a boolean.

I'm open to relaxing the restriction.  I considered using some more 
general term, but balked because introducing a new term to describe a 
more relaxed kind of predicate, just for the hash table chapter, seemed 
questionable to me.  Let me know what you think.  One possibility would 
be to leave it as returning a boolean for the initial draft, and change 
it later.

Anton