Email list hosting service & mailing list manager

Community preference so far? taylanbayirli@xxxxxx (26 Sep 2015 17:29 UTC)
Re: Community preference so far? Alex Shinn (29 Sep 2015 02:43 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (29 Sep 2015 09:17 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (29 Sep 2015 11:00 UTC)
Re: Community preference so far? Alex Shinn (30 Sep 2015 03:16 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 09:37 UTC)
Re: Community preference so far? Alex Shinn (30 Sep 2015 14:02 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 20:44 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (01 Oct 2015 08:36 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (29 Sep 2015 11:36 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (01 Oct 2015 12:53 UTC)
Re: Community preference so far? Alex Shinn (30 Sep 2015 03:32 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 08:56 UTC)
Re: Community preference so far? Alex Shinn (30 Sep 2015 09:38 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 09:46 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 10:03 UTC)
Re: Community preference so far? Evan Hanson (30 Sep 2015 11:54 UTC)
Re: Community preference so far? taylanbayirli@xxxxxx (30 Sep 2015 22:34 UTC)
Re: Community preference so far? Per Bothner (29 Sep 2015 11:14 UTC)
Re: Community preference so far? John Cowan (29 Sep 2015 12:07 UTC)
Re: Community preference so far? Per Bothner (29 Sep 2015 12:47 UTC)
Re: Community preference so far? Alex Shinn (30 Sep 2015 09:15 UTC)

Re: Community preference so far? taylanbayirli@xxxxxx 01 Oct 2015 08:35 UTC

xxxxxx@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> - I will specify that the hash function passed to make-hashtable *may*
>   be passed a second bound argument, and the hash functions will take
>   optional bound arguments.
>
> This covers the gigantic tables use-case.
>
> I'm not entirely happy about the last one, but can't think of a better
> solution.  The other two I'm fairly happy about, because they're very
> non-intrusive changes and cleanly solve our problems.

I decided to slightly break R6RS compatibility there, since it's for
very rare cases anyway: as long as the built-in foo-hash are extended
alongside make-hashtable, code like (make-hashtable string-hash ...)
keeps working as is; the only thing affected are custom hash functions,
which are probably a pretty rare use-case, and they only need to accept
one more argument and may just ignore it.

That avoids the weird "may pass a second argument" semantics.

Taylan