From: David Alan Black <dblack@...>
Date: 2000-12-16T00:17:47+09:00
Subject: [ruby-talk:7321] Re: Why isn't Perl highly orthogonal?

Hello --

On Fri, 15 Dec 2000, Ben Tilly wrote:

> David Alan Black <dblack@candle.superlink.net> wrote:
> >I'm not sure what it is you're saying wouldn't work.  For example:
> >
> >a = [1,2,3,4,5]
> >b = a.map do |e| [e,-e] end
> >c = b.map_with_indices do |e,i| "element #{i} is #{e.inspect}" end
> >
> >p c[2]  # => "element 2 is [3, -3]"
> 
> I was thinking of the following:
> 
>   a = [1, [], [3,4,[]]]
> 
> Pass that to flatten and you will get [1,3,4]. which is
> likely not what someone with that data structure intended
> to do!

Right.  But who's passing anything to flatten?  Hmmm....  Maybe you're
still thinking of my original example?  But even there, the flattening
affects only the result array, not the input array:

[1, [], [3,4,[]]] .map do |e| [e.inspect, "hello"]  end .flatten

 => ["1", "hello", "[]", "hello", "[3, 4, []]", "hello"]

The flattening was just to show that you can get more elements out
than you put in, which I think was what you originally said you'd had
trouble with.  If you don't flatten (which is fine with me -- really!
I don't mind! :-) then you get an array of arrays -- which may be what
one wants in a given case, but would not have made the point.

And (just to clarify) my map_with_indices method doesn't flatten
anything.  It just, umm, maps with indices:

  a = [1, [], [3,4,[]]]
  a.map_with_indices do |e,i| puts "element #{i} is #{e.inspect}" end

  element 0 is 1
  element 1 is []
  element 2 is [3, 4, []]

> >Yes and no.  I probably should have written "In fact" rather than
> >"Then again", above.  My first line of thought was: since the method
> >syntax turns a,b into [a,b] anyway, it's no big deal that we have to
> >write [a,b] in the iterator block.  But I do wonder now why the same
> >a,b syntax isn't allowed in such a block (where it would return [a,b])
> >  -- no implications of non-Ruby-esque list behavior).
> 
> I don't have enough of a sense yet to even try to say what
> Ruby-esque behaviour should be.  Sorry.

Don't apologize :-)  I just meant that it seemed to me that a,b could
behave in iterator blocks as it does in method definitions -- i.e.,
that the a,b syntax per se did not have to introduce ambiguities or
imply unexpected list behavior.  My characterization of it in terms of
Ruby-esque-ness was really just referring back to your earlier
statement:

  I don't think that Ruby is list-oriented or that list-oriented ways
  of thinking are a good fit for it.  Having lists with variable numbers
  of arguments is not part of the basic design and I don't think should
  be hacked on top when it doesn't fit conceptually. 

Now, come on Ben, admit it -- there's just a *little* bit of
willingness to say what is and is not Ruby-esque creeping in around
the edges, isn't there? :-)


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav