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)
|
"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