Jos Backus <josb / cncdsl.com> wrote:
>
>On Tue, Dec 12, 2000 at 05:09:39AM +0900, Craig Berry wrote:
> > I would once have been offended that Perl provides a grep built-in which
> > can be trivially implement in terms of map.
>
><off-topic>
>Isn't it the other way around? You can't make map return a smaller number 
>of
>elements than it was called with, unlike grep.
></off-topic>

I suspect that this thread is showing up on the mailing list
from a thread cross-posted to a Perl group.  (At least it
started that way.)  Wouldn't it make sense to have the mailing
list not get cross-posted threads?  (Particularly since our
responses won't be cross-posted.)

Answering the question, in Perl the list of returns to map
is turned into one long list and returned.  A sub that
returns the original element or the original element based
on a test would make map() work like grep().  In fact this
is pretty much how grep() is implemented.

In Ruby the two concepts are orthogonal.  I don't yet know
if you can have a function that returns different numbers
of elements different times.  Certainly the first thing I
tried to do with map was return 2 elements for 1.  (Looking
at a case where I know current production versions of Perl
doesn't scale.)  I couldn't see how to do it.  And grep
itself cannot be used with arbitrary blocks.  (Therefore
it is truer to the actual name of the function!)

I have some ideas for extensions to Ruby's map function
which would make it more powerful.  Basically have it
send the block arguments in chunks of whatever number of
arguments the block wants, and then have it just push all
of the output into a single return array.  I don't know if
this makes any sense/fits in Ruby's semantics though.
Until I finish reading the book take this as an observation
from someone without a good sense for Ruby.

Cheers,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com