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)

Re: New names for some operations taylanbayirli@xxxxxx 13 Sep 2015 20:04 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