Email list hosting service & mailing list manager

choose-and-remove! operation Arthur A. Gleckler (11 Sep 2015 18:14 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (11 Sep 2015 19:00 UTC)
Re: choose-and-remove! operation Arthur A. Gleckler (11 Sep 2015 22:10 UTC)
Re: choose-and-remove! operation John Cowan (12 Sep 2015 03:10 UTC)
Re: choose-and-remove! operation Arthur A. Gleckler (12 Sep 2015 03:16 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 05:12 UTC)
Re: choose-and-remove! operation John Cowan (12 Sep 2015 05:31 UTC)
Re: choose-and-remove! operation John Cowan (12 Sep 2015 03:03 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 12:43 UTC)
Re: choose-and-remove! operation John Cowan (12 Sep 2015 14:23 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 19:52 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 20:29 UTC)
Re: choose-and-remove! operation Arthur A. Gleckler (12 Sep 2015 20:51 UTC)
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 22:02 UTC)

Re: choose-and-remove! operation taylanbayirli@xxxxxx 12 Sep 2015 20:29 UTC

"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:

> (choose-and-remove! hash-table) => key, value
>
> The idea is that it picks a key-value pair at random, removes it, and
> returns it.

Given my new hashtable-find (not in draft #3, but seen in the live
version), this can be done like:

    (define (hashtable-pop! ht)
      (let-values (((key value found?) (hashtable-find (lambda () #t) ht)))
        (assert found?)
        (hashtable-delete! ht key)
        (values key value)))

and it gives you flexibility in deciding what to do in the no-entries
case; here just an error via assertion.  So I think I'll leave
hashtable-pop! out of the spec.  It could save you a call to the hash
function (in hashtable-delete!) if provided directly instead of
implemented like this, but I don't think that matters.

Taylan