New names for some operations
taylanbayirli@xxxxxx
(13 Sep 2015 12:13 UTC)
|
Re: New names for some operations
John Cowan
(13 Sep 2015 19:01 UTC)
|
Re: New names for some operations
taylanbayirli@xxxxxx
(13 Sep 2015 20:19 UTC)
|
Re: New names for some operations
John Cowan
(13 Sep 2015 22:20 UTC)
|
Re: New names for some operations
taylanbayirli@xxxxxx
(14 Sep 2015 08:29 UTC)
|
Re: New names for some operations
Shiro Kawai
(13 Sep 2015 23:28 UTC)
|
Re: New names for some operations
John Cowan
(13 Sep 2015 23:45 UTC)
|
Re: New names for some operations
Shiro Kawai
(13 Sep 2015 19:27 UTC)
|
Re: New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 20:04 UTC)
|
Re: New names for some operations
John Cowan
(13 Sep 2015 20:11 UTC)
|
Re: New names for some operations
Shiro Kawai
(13 Sep 2015 20:25 UTC)
|
Re: New names for some operations
taylanbayirli@xxxxxx
(13 Sep 2015 21:46 UTC)
|
Re: New names for some operations
taylanbayirli@xxxxxx
(14 Sep 2015 09:39 UTC)
|
Re: New names for some operations
Arthur A. Gleckler
(13 Sep 2015 19:42 UTC)
|
Re: New names for some operations
taylanbayirli@xxxxxx
(13 Sep 2015 19:57 UTC)
|
Re: New names for some operations
Arthur A. Gleckler
(14 Sep 2015 03:25 UTC)
|
Re: New names for some operations
John Cowan
(14 Sep 2015 03:38 UTC)
|
Shiro Kawai <xxxxxx@gmail.com> writes: > On Sun, Sep 13, 2015 at 2:13 AM, Taylan Ulrich Bayırlı/Kammer > <xxxxxx@gmail.com> wrote: > > - hashtable-fold -> hashtable-sum > > Once again, argument order for one, and more importantly different > semantics. "Sum" is a good name because it makes it obvious that > the given procedure should be associative and commutative in a > sense. > > > Another option can be hashtable-reduce. > > "Reduce" has precedence in CL and some other languages but the usage > seems a bit more liberal than "fold" - some allows omitting initial > value, for example. Well, srfi-1 has reduce, unfortunately. But the > combined name xxx-reduce hasn't been used as much as xxx-fold in > Schemes. Hmm, I guess that's a good point. I've been suggested 'reduce' before, but ignored the consideration because our hashtable-reduce would have quite different arguments from SRFI-1 reduce. But you're right in that it's not used much outside SRFI-1, so that should actually be fine. > What's bothers me on sum is that it's not only suggest associativity > and commutativity, but also implies the elements (to be fold) and the > accumulated value are of the same type. In hashtables, the elements > are actually a key and a value, so confusion is less likely, but if we > want to extend xxx-sum for a general name of the "Container-first" > pattern, the implication may get in the way. Indeed. I will change it to -reduce then. Thanks! Taylan