From: trans <transfire@...>
Date: 2009-06-19T08:14:04+09:00
Subject: Re: each by arity



On Jun 17, 6:22 am, Robert Dober <robert.do...@gmail.com> wrote:
> On Wed, Jun 17, 2009 at 6:49 AM, trans<transf...@gmail.com> wrote:
>
> > On Jun 16, 7:43 pm, Robert Dober <robert.do...@gmail.com> wrote:
> >> On Tue, Jun 16, 2009 at 12:33 PM, trans<transf...@gmail.com> wrote:
>
> >> > On Jun 16, 2:10 am, Robert Klemme <shortcut...@googlemail.com> wrote:
>
> >> >> Question is whether it is clever to duplicate all methods with another
> >> >> one that has "_slice" appended to the name.  I personally favor the
> >> >> approach with Enumerator, e.g. depending on version
>
> >> > Not clever... facetious. Of course Enumerator is useful, and with 1.9
> >> > fairly elegant. But rather, the question is why we must do
>
> >> >  enum.each_slice(2).map {|a,b| ...}
>
> >> > when
>
> >> >  enum.map {|a,b| ...}
>
> >> > could be made to work. This is especially interesting b/c it seems the
> >> > underlying implementation stands to be simpler and faster by doing so.
>
> >> That is intriguing and I am surprised.
>
> >> However, why should
>
> >>   enum.map{ |a,b| }
> >> have the semantics of
> >>   enum.each_slice( 2 )....
> >> and not
> >>    enum.each_cons( 2 ).... ?
>
> >> Maybe we need to push the abstraction even higher. Hopefully you
> >> understand what that sentence means, because I do not, but it felt
> >> just right to write it. Strange, strange.
>
> > Simply b/c cons is uncommon. We want to iterate over elements once and
> > only once, where as cons hits on the same elements multiple times. Of
> > course, I see no reason cons could not look at arity too.
>
> Maybe we should map leave alone and use the enumerable approach
>
> coll.cons.each{ |a,b| ...
> coll.slice.each { |a,b|...

Hmm... I point out the Array#slice is already a method.

> I like this because I am used to "waiting" in proxy objects for what
> they are really to be used later, but it might be troubling for
> others.
> Do you think it is a good idea to implement it in Facets first and ask
> for inclusion into the core after having some more feedback from
> users?

Perhaps, but I must think about it some more. Presently one would do
(in 1.9):

  coll.each_slice(n){ ... }
  coll.each_cons(n){ ... }

If one wanted to map over that:

  coll.map.each_slice(n){ ... }
  coll.map.each_cons(n){ ... }

correct?

So how do we best achieve "by arity" without stepping on present toes?
It would be nice to have a coherent idea about it as well. It would be
interesting to look at this kind of thing in a variety of languages
actually. OCaml for instance has already been mentioned. I'll have to
look that up.

T.