This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 36: hash-tables

2011-01-24 06:58:39
WG1 - Libraries
alexshinn
major
alexshinn
wontfix
source
closed
2010-02-23 17:10:57
defect

R6RS and SRFI-69 both provide hash-table interfaces. Do we provide either of these, or try to provide some primitives on which efficient hash-tables can be implemented?

SRFI 69 is supported (according to the documentation) by PLT, MIT, Chicken, Guile, Kawa, SISC, Chibi, SCM, IronScheme, Larceny, STklos, SigScheme. The median value for the number of Schemes supporting a SRFI is 7 (out of my table of 30 Schemes and 76 SRFIs at http://tinyurl.com/scheme-s5 ), so this is better supported than most SRFIs, but nothing like SRFI 9 (25 Schemes) or SRFI 6 (24 Schemes).

milestone

I am against providing hash tables in WG1 Scheme. If they are provided, people will tend to use them by default, whereas in typical Schemes they are only efficient when you have more than 50 keys. Below that, a-lists work fine and are better integrated into the rest of Scheme.

I would also oppose, and for much the same reasons as comment #2.

hash-table engineering is an art, and the unwary use them very poorly.

The WG voted to place hash tables in a module, but did not specify what it should contain.

resolutionwontfix
statusnewclosed

WG1 voted not to provide hash tables.