Email list hosting service & mailing list manager

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