This page is part of the web mail archives of SRFI 69 from before July 7th, 2015. The new archives for SRFI 69 contain all messages, not just those from before July 7th, 2015.
Thank you for these constructive comments. I'll summarise my views by kind of change: ... wording changes: Most of these I find very good and I thank you for writing them. I will seek more conciseness at some points, but overall, I'm going to include the changes in abstract and rationale. ... dropping this and that: I would like to include routines that are likely to be rewritten every now and then by programmers using hash tables. In principle, we could split the "core routines" and the "library routines" in different SRFI's is we want to be puristic, but I think it's not worth the added trouble. So I'm not going to drop any function just because it does not make programs more portable -- it should also be too marginal for common use to be dropped. That said, I could drop the constructor shorthands in favor of documenting the correct arguments to make a numeric hash table and so on. Maybe I should include an examples section. > Drop size-hint. Size-hint may be ignored as currently specified, thus its > status as an optional argument to hash table constructors does nothing to > make efficient use of hash tables portable. Allow implementations to > extend the parameters arbitrarily to make implementation specific > improvements. Maybe this is a good approach. There will obviously be demand for implementation-specific extensions in the constructor. > From the document: > If some key occurs multiple times in alist, it is unspecified which > of the corresponding values will end up in hash-table. > Why not specify that they are added in the order they appear in the alist, > such as MzScheme does. If this is not the case, portable programs can't > rely on this function unless it is never the case that a key appears twice > in the alist. Is there something gained from this being unspecified that > outweighs the loss in portability? There is no external syntax for hash > tables so it seems to read and write hash tables portably one needs a well > specified alist->hash-table and hash-table->alist. This is a complicated issue. My implementation currently adds the value from the _last_ association in the list, which is probably what you mean ty "added in the order they appear". But because assoc&friends returns the first occurrence, picking the first value would make the API more consistent with alists. OTOH, most times I've seen alists with duplicate keys, it has been as a result of a programming error. And I can't think of a situation where the user would _want_ the implementation to pick the value from the last association of the list into the hash table. So, does anybody have experience about what kind of stuff are duplicate-key alists used for? ... technical issues: Caveats similar to MzScheme's apply to these hash tables, too. I could also elaborate what kind of "unpredictability" is caused by in-place mutation of keys. This kind of caveat applies to every equality predicate, not only equal? -- even eq?, unless somebody can find a place in R5RS that explicitly says that an object's eq?-uivalence is preserved when it is mutated in-place. And then this: > Also note that the current specification is not correct: > Procedure: hash-table-ref/default hash-table key default -> value > Equivalent to (hash-table-ref hash-table key (lambda () default)). Depends on what your definition of "equivalent" is. You took "default" to be a syntactic metavariable, while I took it to be a variable. Maybe I should simply say "evaluates to" instead of "equivalent to". Panu -- personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: panu.kalliokoski@xxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/