[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue: HASH-TABLE-ACCESS (version 2)
- To: vanroggen%aitg.DEC@decwrl.dec.com
- Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)
- From: masinter.pa@Xerox.COM
- Date: 14 Nov 88 14:57 PST
- Cc: email@example.com
- In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Mon, 17 Oct 88 17:16:05 PDT
I think we need a new version of this proposal that spells out the answers
to the questions that arose in response to version 2. If things are not
specified, give the reason for not specifying them; if the return values
are implementation-dependent, give that as well.
The value of HASH-TAbLE-REHASH-SIZE and HASH-TAbLE-REHASH-THRESHOLD are
implementation dependent, and guaranteed to be greater than or equal to the
values given to MAKE-HASH-TABLE, and idempotent, in that if you make a hash
table with the same values as a given hash table then the -REHASH-SIZE and
-REHASH-THRESHOLD of the newly created one will be the same as the input
values. (This says that they may be thresholded upward in some
HASH-TABLE-SIZE should be greater than or equal to the count of things
MAPHASH would iterate over, and HASH-TABLE-TEST will return one of the
symbols EQ EQL EQUAL (or, if HASH-TABLE-TESTS passes, EQUALP), even if #'EQ
#'EQUAL #'EQL are given.
Normally implementation-dependent-extensions are explicitly discouraged;
I'm no longer sure at the momemnt whether PACKAGE-CLUTTER would explicilty
disallow such extensions unless they are explicitly allowed, but we should
be cautious in throwing around phrases like "might be
reasonable implementation-dependent extensions" if we don't mean it. I
would take that out, actually.
Walter, as you are the author of this, I'll ask you first to produce a
revision. Will you?