On 8/15/04, [EMAIL PROTECTED] (David Wheeler) wrote:
>On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
>> for all $*IN # all() is junction
>> for each $*IN # each method wants closure if we follow Ruby
>> for next $*IN # next $foo is a loop exit
>
>Hmm. Maybe the problem is that we shouldn't follow Ruby on .each's
>signature. How about we have .apply or .filter do the Ruby implicit
>iteration thing, and keep .each for iterating iterators.
"Each" and "every" are the obvious choices, but I wouldn't want to follow
Ruby exactly: "each" has a definite connotation of "separately", "one at a
time" that works in "for each $foo"; "every" works better for the overall
method.
("All" has an "all at once" sense that fits its junctive use; "next"
certainly has the right meaning: "for next $foo" sounds funnier than "for
each $foo", but "print next $foo" is better than "print each $foo". I
suppose loop-next could be renamed "cont" except that we just renamed the
continue block to NEXT -- perhaps there's some clever way to unify them and
use "next" for both cases?)
>> @bar = @foo.filter:{ $_ * 2 };
>> filter @foo: { $_ * 2 } ==> @bar;
>
>C<filter> is good for this; I like it. But if you decide you need to
>keep it as C<each>,
>then I personally really don't mind using C<every> for the iterator method.
morph @foo: { $_ * 2 } ==> @bar; ? #less typing than "transmute"
Personally, I like "apply", since the actual word "filter" means something
more like 'grep' than 'map', but I guess in computer lingo, filters are
often understood to map stuff. (FOLDOC tells me that Haskell's equivalent
to "grep" is spelled "filter". (Though it might make more sense for the
condition to be negated -- hm, if we have if/unless, while/until, why not
grep/filter?))
-David "munge @foo: { $_ * 2 } ==> @bar; ??" Green
