Damian Conway writes: > I don't object in principle to renaming "grep" to something more self > explanatory (except for the further loss of backwards compatability > and historical Unix reference...though that didn't stop us with > "switch" vs "given" ;-)
But while C<switch> had precedence in computer science in general it didn't have this in Perl; your Switch module is not used much in Perl 5, and Perl 6's C<given> is a substantial improvement over the C<switch> statement in most languages. Whereas C<grep> is a well-known and well-used Perl 5 function, and this functionality is not being changed in Perl 6 (other than being available as a method as well as a function). > The standard--and self-explanatory--CS term for this operation has > always been "filter", which is also currently used by Python, Scheme, > Haskell, and numerous other languages, so *if* we're going to change > it from "grep", we ought to change it to "filter". Yes, but C<grep> is a just one type of filter: it's specifically a filter on elements in a list. By deploying the generic word "filter" for this specific use we'd be clobbering its use for any other sorts of filters -- on lines, source code, coffee, whatever. I have no statistics but I'd guess that C<filter> is a reasonably common sub or method name in Perl 5 code found in the wild -- much more so than C<say> or C<given> -- and that it's currently being used to filter many things other than lists. The above are not conclusive reasons why we shouldn't rename C<grep> to C<filter> (I'm not that bothered either way myself), but just some points to bear in mind and reasons to be cautious. Smylers
