From: Robert Dober Date: 2010-04-17T10:37:14+09:00 Subject: Re: Is it possible, a fully general Enumerable#recursive ? On Sat, Apr 17, 2010 at 1:17 AM, Caleb Clausen wrote: > On 4/16/10, Colin Bartlett wrote: >> On Mon, Apr 12, 2010 at 6:00 PM, Caleb Clausen wrote: >>> I find this subject extremely confusing. >>> Colin's answer to my last email is still causing me puzzlement. >> Two apologies: first, for not replying sooner to this. >> (I was going to do a combined response to this and to what Tom and Robert >>  have said, hence the delay: I then decided that it would be better >>  to make a reply to you on this specific point, and follow up later >>  with more general observations. I think I've nearly got a proof of concept >>  thing working. That said, I - for now - still agree with Tom's comment: >>    "After working on this for far too long, I have concluded that >>     a highly generalized implementation of recursion for all >>     (or at least most) enumerable methods not feasible.") >> >> Second, sorry for causing puzzlement. I (mostly) try not to be >> deliberately obfuscatory. Was it (1) or (2) (or both!) >> of my reply to your post that was/is causing puzzlement? >> >> (1) Using #map inside #visit combined with using Enumerable#map >>     seems to (within #visit) produce the structure of the original array, >>     but with nil values instead of the original values. >>     (Changing #map inside #visit to #each gets back the original values.) >> >> (2) Irrespective of the internal results from #visit, Enumerable#map >>     collects the successive results of the block for Enumerable#map >>     into a new (flat) array. > > It's more like: >  (3) Too much recursion just makes my brain hurt. > > It's not really your failing... I just have difficulty understanding > these things. It's not like your code was particularly complicated, > but I couldn't keep all the implications straight in my head. > > >> Does the following reduce the puzzlement? > [snip] >> Does that help in any way? > > Yes, some. Thanks for the explanation > >>> I have often found that too much recursion is confusing. >> Yes - me too! My test version of a "general" recursive enumerator >> looks more like C (or Fortran!) code than Ruby. >> I sort of instinctively think in terms of what's underlying the recursion, >> which can get in the way of me just using recursion, >> when just using recursion might well be easier! > > Ah, good. I'm glad I'm not the only one. There's a good reason why I > refuse outright to look seriously at functional languages. > >>> This whole problem is going to be a lot easier if it's structured >>> as an external iterator first and foremost. >>> I have an extern iterator library (sequence) >>> maybe I can figure out how to do this within that. >>> (I don't really have a good grip on how Enumerator works, myself...) >> >> Provided I understand more or less correctly what you mean by >> an "extern iterator library", then it might be something that >> I could understand! > > Basically, external iterator == no recursion. Enumerator is an > external iterator. > > I'm still trying to work out (in my copious free time, hah!) how this > would work and if it's worth it. An external iterator has to keep an > 'index' internally so it knows where it is in the data structure. In > this case, the 'index' is not a simple integer, its something more > like an xpath. > > On 4/16/10, Robert Dober wrote: >> On Fri, Apr 16, 2010 at 11:20 PM, Colin Bartlett >> wrote: >> >>>   "After working on this for far too long, I have concluded that >>>    a highly generalized implementation of recursion for all >>>    (or at least most) enumerable methods not feasible.") >> I beg to differ >> module Enumerable >>   def recursive_each &blk >>     each do | ele | >>       Enumerable === ele ? ele.recursive_each(&blk) : blk[ele] >>     end >>   end >> >>   def rec_enum; enum_for :recursive_each end >> end >> >> x=[ :a, 42, [:b, :c], {:a=> 42, :b => [1,2]}] >> >> rx = x.rec_enum >> >> p rx.to_a >> p rx.any?{ |x| x > 41 rescue false } >> p rx.map{ |x| "<#{x}>" }.join(", ") > > Sorry, but: > > y=[9,8,7,[6,5,4,[1,2,3]]] > ry=y.rec_enum > ry.sort  #=> [1, 2, 3, 4, 5, 6, 7, 8, 9], should be [1,2,3,[4,5,6,[7,8,9]]] > > Why? What is the purpose of rec_enum then? R. -- The best way to predict the future is to invent it. -- Alan Kay