hashtable-clear-copy
taylanbayirli@xxxxxx
(11 Sep 2015 14:52 UTC)
|
Re: hashtable-clear-copy
John Cowan
(11 Sep 2015 14:58 UTC)
|
Re: hashtable-clear-copy taylanbayirli@xxxxxx (11 Sep 2015 15:36 UTC)
|
Re: hashtable-clear-copy
Arthur A. Gleckler
(11 Sep 2015 16:39 UTC)
|
Re: hashtable-clear-copy
John Cowan
(11 Sep 2015 16:47 UTC)
|
Re: hashtable-clear-copy
John Cowan
(12 Sep 2015 06:11 UTC)
|
Re: hashtable-clear-copy taylanbayirli@xxxxxx 11 Sep 2015 15:36 UTC
John Cowan <xxxxxx@mercury.ccil.org> writes: > Taylan Ulrich Bayırlı/Kammer scripsit: > >> (hashtable-clear-copy ht) ;initial capacity has default value > > I had this at one time, under the name of hashtable-empty-copy (which I > think is a less confusing name) but flushed it because I couldn't think > of use cases. Maybe I'll remove it again, letting those few use-cases be filled by uses of make-hash-table's extended/fixed semantics. I find it fairly harmless even if were useless though, since its specification is short and the semantics clear. It can't lead to obfuscated code, from what I can imagine. > As you add things and I remove them, eventually we may converge modulo > names, in which case we can safely leave it up to the WG to choose. If we sufficiently converge, I might give up the R6RS naming scheme and let SRFI-69 naming win out, since it seems more commonly supported. My work on specifying weakness support and read syntax would be integrated into your SRFI. However, you'd need to remove many of the utility procedures with strange semantics, remove the bimap API, and perhaps most importantly, remove the dependency on SRFI-114. Taylan