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