:hash-function behavior in make-hash-table inconsistent with documentation

Bug #1888028 reported by Jacek Złydach
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Undecided
Unassigned

Bug Description

Version: SBCL 2.0.6 X86-64

Test case:

In the REPL, enter: (make-hash-table :hash-function nil)

Expected behavior:

A regular hash table, equivalent to one created by plain (make-hash-table), OR documentation directly mentioning that the argument MUST be a valid function designator if it's explicitly specified.

Observed behavior:

Condition of type UNDEFINED-FUNCTION: The function COMMON-LISP:NIL is undefined.

Context:

The SBCL 2.0.6 documentation for :hash-function argument states:

"If nil (the default), a hash function based on the test argument is used, which then must be one of the standardized hash table test functions, or one for which a default hash function has been defined using sb-ext:define-hash-table-test. If hash-function is specified, the test argument can be any two argument predicate consistent with it. The hash-function is expected to return a non-negative fixnum hash code."

The above text - in particular the beginning of the first sentence - seems to imply that explicit NIL value should be equivalent to not passing :hash-function argument at all. I believe that either NIL argument should be allowed, or the documentation should state explicitly that :hash-function must be a function designator.

Extra info:

- uname -a: Linux enterprise 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
- *FEATURES*: (:SWANK :DEV :QUICKLISP :QUICKLISP-SUPPORT-HTTPS :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ROS.INIT :X86-64 :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE :SBCL :UNIX)

Revision history for this message
Douglas Katzman (dougk) wrote :

I'll reject NIL as a hash-function. It makes no sense, it's just opening a can of worms to suggest that there should be any kind of defaulting logic in these cases:
 (make-hash-table :test #'string= :hash-function nil) ; there is no default hashing for STRING=
 (make-hash-table :test #'equal :hash-function nil) ; default is known, but please don't do this
or
 (defun mytest (a b) (if (numberp a) (= a b) (eq a b))) ; a random user-defined test
 (make-hash-table :test #'mytest :hash-function) ; what could this even mean? I have no idea.

Douglas Katzman (dougk)
Changed in sbcl:
status: New → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.