Re: renaming grep to where
Jonathan Lang skribis 2006-09-19 16:39 (-0700):
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
There's a neat trick for this: .grep:{ not ... }
HTH :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: renaming grep to where
Just to point out that it's probably worth going back and rereading the
earlier iterations of this discussion, in December 2002 (subject: purge: the
opposite of grep) and November 2005 (subject: Classification syntax). That
way, those who repeat history are condemned to study it. ;-)
In summary, when we last left this discussion, Larry was inclined to retain
the name 'grep', and to add a 'classify' built-in that would allow positional
or named partitioning of a list. For example (in updated syntax):
(:@sheep, :@goats) := classify { /baaa/ ?? 'sheep' !! 'goats' } @list;
(@x, @y, @huh).pairs := classify { /she/ ?? 0 !! /he/ ?? 1 !! 2 } @list;
%people_who_use
= classify { /[EMAIL PROTECTED]/ ?? 'perl' !! /[()]/ ?? 'lisp' !!
'???' }
@people;
In other words, classify() takes a list of values, examines each in turn, and
ascribes a label value to it. The call returns a list of pairs, where each
pair key is one of the label values and each pair value is an array of all the
list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if we do
decide to change the name, I suspect 'keep' might be readable, short, SWIM,
and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
Damian
Re: renaming grep to where
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a label value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. classify is the real grep
2. convenience function, keep is probably a macro
3. use List :compat will get you a grep just as it will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
Re: renaming grep to where
Aaron (): OK then. Just so that I can type of the final result in S29, let's see if everyone agrees to several points that have been made in this thread: 1. classify is the real grep 2. convenience function, keep is probably a macro 3. use List :compat will get you a grep just as it will likely get you mv on the OS module, etc. Is any of this going to break the bank? If not, I'll get it in today. You mean grep is going away? I'd had hoped that enough people had expressed their I like grep and Don't fix what isn't broken opinions for it not to... Oh well. I'll miss it. -- masak
Re: renaming grep to where
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, keep implies throwing
the rest away,I.e., modifying the list. Select has the advantage of
lacking that connotation. To avoid dissonance with the two perl5
selects, we could go with a synonym like choose or, in the 4-char
category, pick. But my vote is still to keep grep as grep.
On 9/20/06, Aaron Sherman [EMAIL PROTECTED] wrote:
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a label value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. classify is the real grep
2. convenience function, keep is probably a macro
3. use List :compat will get you a grep just as it will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
--
Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
[EMAIL PROTECTED] wrote: I still don't think we have a consensus that grep needs to be renamed, much less what it should be renamed to. To me, keep implies throwing the rest away,I.e., modifying the list. Select has the advantage of lacking that connotation. To avoid dissonance with the two perl5 selects, we could go with a synonym like choose or, in the 4-char category, pick. But my vote is still to keep grep as grep. I don't know that we have consensus, I was just trying to bring this thread in for a landing so I can write it up. As S29 stands now, there is a grep, and there is no classify. At least the latter needs to be fixed, per Damian pointing out lost history that I should have been on top of. I'll wait on the removal of grep for any(@larry) to make a clear statement to that effect.
Re: renaming grep to where
Quoth [EMAIL PROTECTED]: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. I would second that strongly. Perl6 is already different enough from Perl5 for good reasons; making it different for bad reasons seems to me a really bad idea. If this sort of change is on the cards, then for consistency a serious effort should be made to remove *all* Unixisms from Perl (unlink, flock, fork, and all the signal stuff spring to mind; a case could be made for the filetest ops as well). I think that that level of culture- and history-loss would be a real shame; I can see however that others may think it more important to make Perl more platform-agnostic in character as well as in implementation. Ben -- 'Deserve [death]? I daresay he did. Many live that deserve death. And some die that deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends.' [EMAIL PROTECTED]
Re: renaming grep to where
Just a perl 5 physicist here. I had to run to the Camel book to find out that grep existed in the world of perl. But I have done this (from memory): $stuff_in_lines = `grep suntide *.txt`; I never thought about the potential for serious ambiguity in interpretation. The UNIX grep tool is really dissimilar considering that it uses a different regular expression syntax. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: renaming grep to where
On 20 Sep 2006, at 18:41, Doug McNutt wrote: I never thought about the potential for serious ambiguity in interpretation. The UNIX grep tool is really dissimilar considering that it uses a different regular expression syntax. (perl grep doesn't have to be used with an RE of course) I guess there's a fine line between renaming things in Perl 6 because it's possible and because it's desirable. Once you're off the leash of the old language there's a perceived obligation to give everything the name that best represents its purpose - but things inhabit the names they're given. The Beatles probably sounded like a really dumb name for a band once. Is there a serious objection to letting it be? 'select' has POSIX and SQL meaning, 'where' has a SQL meaning, 'grep' has a Unix command connotation - but 'grep' has the benefit that it also has an existing perl connotation. -- Andy Armstrong, hexten.net
Re: renaming grep to where
On Wed, Sep 20, 2006 at 06:54:11PM +0100, Andy Armstrong wrote: : The Beatles probably sounded like a really dumb name for a band once. : : Is there a serious objection to letting it be? Let it be. :) Larry
Re: renaming grep to where
On 20 Sep 2006, at 19:05, Larry Wall wrote: Let it be. :) I could just as easily have called for a revolution :) -- Andy Armstrong, hexten.net
Re: renaming grep to where
names they're given. The Beatles probably sounded like a really dumb name for a band once. But maybe less dumb than 'The Quarrymen', which was the original name of the band. (They all went to Quarry Bank school, now Calderstones.) Perhaps the renaming, unfettered by their history or by a desire to not fix what ain't broken, helped them along their way to superstardom. I'm not sure if there is a lesson to be learned here. As I haven't previously spoken on the subject, I'll weigh in to express a slight preference for the name grep, though I like Larry's idea of a generalised 'divvy'. Last year, teaching ML, I taught the definition of the 'filter' function as 'grep', simply because I'd forgotten that it was called 'filter' in ML. Mind you, as it had been a year or two since I'd last used ML, I'd also forgotten a few of the other keywords, a problem I have with other languages too. Do you 'throw' or 'raise' an exception? Do you use 'else if', 'elseif', 'elsif', or 'elif'? I can see how aliases can be a Bad Thing, but when my mind is elsewhere I would appreciate some loan words from other languages. -- And for mile after mile you'll never see me tire/You'll never me me slow down for a while/'Cause I am the fox, like it or not/I'm always gonna be there running over the rock/ Yes I am the fox, a fascinating cross/ Of sharp as a whip and tough as an ox Bernie Taupin, 'The Fox' pgpWI4WXRDtv7.pgp Description: PGP signature
Re: renaming grep to where
On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote: On 20 Sep 2006, at 19:05, Larry Wall wrote: Let it be. :) I could just as easily have called for a revolution :) No, you should have quoted differently: On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom: Let it be. :) --
Re: renaming grep to where
On Wed, Sep 20, 2006 at 11:44:49PM -0400, John Macdonald wrote:
: On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
: On 20 Sep 2006, at 19:05, Larry Wall wrote:
: Let it be. :)
:
: I could just as easily have called for a revolution :)
:
: No, you should have quoted differently:
:
: On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom:
: Let it be. :)
my Yellow sub marine { @we.all.live }
Larry
Re: renaming grep to where
Darren Duncan wrote: So filter is now my preference for a new name, and if grep is kept, then that can be an alias for it; We've also had a policy of removing synonyms (e.g. for/foreach), so I think we should have only one name for any one function. Damian
Re: renaming grep to where
Darren Duncan writes: At 6:26 AM +0200 9/19/06, Damian Conway wrote: ... *if* we're going to change it from grep, we ought to change it to filter. I agree. So filter is now my preference for a new name, and if grep is kept, then that can be an alias for it; No: no aliases. Perl does not have a tradition of these, and overall aliases tend to add to confusion -- with the result that everybody ends up having to learn both (or all) names anyway. And I'm pretty sure Larry has previously spoken out against aliases. MySQL's SQL dialect has a few synonyms. On numerous occasions I've seen SQL that I didn't think I understood only to discover I knew a different name for the same thing, or _vice versa_. use English provides lots of aliases in Perl 5, but note how rarely they are used in practice. Even if somebody chose to use English in all her code she would still have to learn the punctuation variable names to read others' code, get help from fora, and so on. And I can honestly say that when reading Damian's 'Perl Best Practices' when I saw a reference to C$EVAL_ERROR I first of all stopped to see where it had been declared before realizing it was just another name for the variable I use every day as C$@. filter should be the canonical name for most documentation, though. That's one of the problems with aliases: if the docs generally use Cfilter then when a reader encounters code using Cgrep for the first time he will be more puzzled than if either name had been used consistently through out. And you can be sure that most existing Perl 5 coders who are used to Cgrep would continue to use that name in Perl 6, regardless of what the docs say. I do not think renaming Cgrep to Cfilter is a terrible idea, but if it's being done then it should be done properly, not half-heartedly with an alias. Smylers
Re: renaming grep to where
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 Cswitch 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 Cgiven is a substantial improvement over the Cswitch statement in most languages. Whereas Cgrep 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 Cgrep 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 Cfilter is a reasonably common sub or method name in Perl 5 code found in the wild -- much more so than Csay or Cgiven -- 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 Cgrep to Cfilter (I'm not that bothered either way myself), but just some points to bear in mind and reasons to be cautious. Smylers
any(@originals) ~~ { .foo eq $bar} (was Re: renaming grep to where)
On 9/19/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
This doesn't seem to be correct.
According to S03 junctions thread through operations, returning
another junction representing the result. Instead of returning the
filtered values, this seems to allways return one of
any(Bool::False) # If all comparisons were false
any(Bool::True) # If all comparisons were true
any(Bool::False, Bool::True) # If some comparisons were false and some true
Testing a concrete example in pugs (r13034):
pugs my @a = (1..10);
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
pugs any(@a) ~~ { $_ 0 }
(Bool::False)
pugs any(@a) ~~ { $_ 0 }
(Bool::True)
pugs any(@a) ~~ { $_ % 2 }
(Bool::False | Bool::True)
--
Markus Laire
Re: renaming grep to where
Smylers wrote: 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 Cswitch 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 Cgiven is a substantial improvement over the Cswitch statement in most languages. Whereas Cgrep 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). IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep, I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules, such as the aforementioned use English. My recommendation: leave it as grep, but leave a note for whomever is going to create the perl6 analog of the English module that they might want to provide a more intuitive name for it. -- Jonathan Dataweaver Lang
Re: renaming grep to where
Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: renaming grep to where
Smylers == Smylers [EMAIL PROTECTED] writes: Smylers No: no aliases. Perl does not have a tradition of these, except for/foreach. :) But I agree with the rest of your position. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: any(@originals) ~~ { .foo eq $bar} (was Re: renaming grep to where)
In a message dated Tue, 19 Sep 2006, Markus Laire writes:
On 9/19/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
This doesn't seem to be correct.
See S09. In particular,
@result = any(@x) ~~ {...};
is equivalent to
@result = grep {...}, @x;
Testing a concrete example in pugs (r13034):
pugs my @a = (1..10);
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
pugs any(@a) ~~ { $_ 0 }
(Bool::False)
pugs any(@a) ~~ { $_ 0 }
(Bool::True)
pugs any(@a) ~~ { $_ % 2 }
(Bool::False | Bool::True)
This feature is unimplemented.
Trey
Re: renaming grep to where
Randal L. Schwartz writes: Smylers == Smylers [EMAIL PROTECTED] writes: Smylers No: no aliases. Perl does not have a tradition of these, except for/foreach. :) I don't reckon one instance is enough to be labelled a tradition! (Um ... actually I forgot about that one. But if I had considered it I still wouldn't've considered it to be a tradition. Honest.) Smylers
Re: renaming grep to where
On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. That said, I'm in favor of the term filter because, as Damian mentioned, that term is used in several other languages. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Sure, but all's fair if you predeclare. Aliases imposed on us all may cause confusion, but presumably, if an individual has asked for an alias, they are willing to risk the potential confusion. For me personally, I can live with filter as an alias for grep. But that's just me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: renaming grep to where
As a random alternative, I note that Ruby's analog to grep is called find_all (though it also has a grep that behaves differently from Perl's). Personally, I'm not enamored of filter because it has connotations of removal... On 9/19/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. That said, I'm in favor of the term filter because, as Damian mentioned, that term is used in several other languages. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Sure, but all's fair if you predeclare. Aliases imposed on us all may cause confusion, but presumably, if an individual has asked for an alias, they are willing to risk the potential confusion. For me personally, I can live with filter as an alias for grep. But that's just me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
Smylers wrote: Randal L. Schwartz writes: Smylers == Smylers [EMAIL PROTECTED] writes: Smylers No: no aliases. Perl does not have a tradition of these, except for/foreach. :) I don't reckon one instance is enough to be labelled a tradition! (Um ... actually I forgot about that one. But if I had considered it I still wouldn't've considered it to be a tradition. Honest.) Tradition is not the issue, especially as Perl 5 did not have macros, so there was no clean way to write aliases (you had to muck with globs to directly munge the symbol table). Still, look at the aliases provided in the standard modules: English.pm - this is nothing BUT aliases File::Copy - mv, cp File::Compare - cmp Cwd - cwd IO::Handle - gets grep is part of Perl 6's Unix legacy, just as . is part of its modern high level language legacy or -e is part of its shell legacy. These things are good ideas that stuck, and as grep is now a verb in many sub-jargons, it makes sense to provide it as an alias for whatever new-fangled term we decide is required to convince newbies to use it (by the way, newbies don't use grep because list transforms confuse and intimidate, not because of the name). Should it come with a tag? Maybe (in fact, I think all of the -X tests should, now that we've decided that we want to keep -Inf as an error). In general, we should probably have a tree of such tags that different modules can use as they see fit. For example: :compat - pull in all compatibility aliases :perl5 aka :compatperl5 aka :languageperl5 - Perl 5 compat aliases :os - pull in all OS-specific aliases :osposix - pull in all POSIX aliases :oswindows - pull in all Windows aliases ... :language... - (e.g. python or c++) language aliases Almost all modules would do nothing at all with these, and most that do anything would stop at :compat, but a few (filesystem-related modules, list manipulation, etc) would dip down into the lower levels. In this way, there is uniformity of expectations. You can always use :compat if you want a full-tilt namespace, and it should work, but if you want P5 compat, you can just use :perl5 and get what you expect (in terms of names, not grammar).
Re: renaming grep to where
(by the way, newbies don't use grep because list transforms confuse and intimidate, not because of the name). I dispute that. List transforms and grep are wholly separate beast, having nothing to do with each other besides the fact that the list transform idiom happens to use grep. It also happens to use map and closures. There's nothing terribly confusing or intimidating about grep itself apart from the name; find all items in this list matching blah is pretty straightforward functionality. -- Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
Mark J. Reed wrote: (by the way, newbies don't use grep because list transforms confuse and intimidate, not because of the name). I dispute that. List transforms and grep are wholly separate beast, This was a minor side-comment. Let's stay focused and not rat-hole on our respective definitions of list transform.
Re: renaming grep to where
On 9/19/06, Aaron Sherman [EMAIL PROTECTED] wrote: This was a minor side-comment. Let's stay focused and not rat-hole on our respective definitions of list transform. Fair enough. Sorry for the distraction. To return to the topic at hand (STAY ON TARGET! STAY ON TARGET!), so far we have these suggestions for grep. 1. grep (it ain't broke, so don't fix it) 2. where (by analogy with the keyword) 3. filter (descriptive and, according to Damian, a CS Standard. Not that I recall using that term in any of my classes, but I'll take his word for it... :)) 4. select (the Rubyometer was feeling neglected) Along with these mix-ins: A. allow grep as an alias for whatever new name (TMTOWTSI, S=spell) B. no aliases nohow (There Can Be Only One) C. compromise between A and B: allow user to request aliases of various flavors, including Perl5 (All's Fair if you Predeclare) I have no horse in this race. My personal preference would be to leave grep as grep. My second choice is select, which to me is more descriptive than filter; it also readily suggests an antonym of reject to do a grep -v (cf. if ! vs unless). But I'd accept filter, too. I definitely vote C, though. No aliases in the core, but no reason not to include modules in the standard set that provide some. -- Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
From: [EMAIL PROTECTED] Date: Tue, 19 Sep 2006 14:26:30 -0400 As a random alternative, I note that Ruby's analog to grep is called find_all (though it also has a grep that behaves differently from Perl's). Personally, I'm not enamored of filter because it has connotations of removal... Hmm. Is this because Perl 5 grep can be used to modify a list in place? Does Perl 6 grep also allow that? The Lisp equivalent is remove-if-not, which otherwise seems like a perfect description of what Perl grep does. On 9/19/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote: . . . That said, I'm in favor of the term filter because, as Damian mentioned, that term is used in several other languages. In that vein, select from SQL should also be mentioned. (I'm not so sure that filter is broadly standard, as Damian asserts, but maybe I haven't used enough languages.) -- Bob Rogers http://rgrjr.dyndns.org/
Re: renaming grep to where
Jonathan Scott Duff wrote: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. Not just that; but also because that's one more thing that perl programmers are going to have to relearn when and if they migrate from 5 to 6. And the more things there are to relearn, the more likely it will be if rather than when. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Sure, but all's fair if you predeclare. Aliases imposed on us all may cause confusion, but presumably, if an individual has asked for an alias, they are willing to risk the potential confusion. Precisely. -- Jonathan Dataweaver Lang
Re: renaming grep to where
On 9/19/06, Bob Rogers [EMAIL PROTECTED] wrote: Hmm. Is this because Perl 5 grep can be used to modify a list in place? Does Perl 6 grep also allow that? The Lisp equivalent is remove-if-not, which otherwise seems like a perfect description of what Perl grep does. Except that Perl lists, unlike Lisp ones, are modifiable, so I'd expect a method with remove in the name to actually remove stuff from the list - which grep doesn't do. It just makes a new list containing only the matching items. In that vein, select from SQL should also be mentioned. Indeed. Ruby also has select (an alias for find_all); as indicated in my last message, that's my new favorite name for this method (second only to keeping grep). -- Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
At 5:48 PM -0400 9/19/06, Bob Rogers wrote:
From: [EMAIL PROTECTED]
Date: Tue, 19 Sep 2006 14:26:30 -0400
As a random alternative, I note that Ruby's analog to grep is called
find_all (though it also has a grep that behaves differently from
Perl's). Personally, I'm not enamored of filter because it has
connotations of removal...
Hmm. Is this because Perl 5 grep can be used to modify a list in place?
Does Perl 6 grep also allow that? The Lisp equivalent is remove-if-not,
which otherwise seems like a perfect description of what Perl grep does.
AFAIK, none of the things we are talking about will modify a list in
place. Rather, they are all pure functions that take a list and a
keep-what-matches condition as arguments and return a new list. And
so they should remain. Modify in place is as simple as assigning the
new list to the old variable.
On 9/19/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote:
. . .
That said, I'm in favor of the term filter because, as Damian
mentioned, that term is used in several other languages.
In that vein, select from SQL should also be mentioned. (I'm not so
sure that filter is broadly standard, as Damian asserts, but maybe I
haven't used enough languages.)
FYI, if you want to talk about SQL or the relational data model, in
that context, both select/project and where/restrict perform
analagous functions, doing filtering of sorts, but in different
dimensions. The select/project takes a subset of the original
table's/relation's columns/attributes, and the where/restrict
takes a subset of the original table's/relation's rows/tuples. Its
the difference between a vertical slice and a horizontal slice.
In Perl terms, (assuming an array of hashes), the project is like a
hash slice; eg:
my @projection = @original.map:{ {$_.a b c} };
Whereas, the restrict is like a grep; eg:
my @restriction = @original.grep:{ $_.{'a'} eq 'foo' };
Suffice it to say that, along those lines, there are 4 terms.
The actual syntax of RM restrict is more like grep than the other 3.
But that doesn't have to matter for us. We don't have to use the
same words as domain-specific languages to name an operation, but a
name that works well in english is very helpful.
-- Darren Duncan
Re: renaming grep to where
Oh, here's a thought ...
In signal processing electronics and such, filters are
often/sometimes named after what they let through. For example,
high pass filter or low pass filter to allow through either high
or low frequencies, for example.
On that note, if this isn't causing another homonym problem, ...
How about pass as a new name; eg:
@filtered = @original.pass:{ condition };
I don't think that this in any way suggests modifying the original.
-- Darren Duncan
Re: renaming grep to where
On Tue, Sep 19, 2006 at 05:38:32PM -0400, Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf. if ! vs unless). But I'd accept
: filter, too.
But which *ect do we call the one that returns both? One would like to
be able to say:
@stuff.direct(
{ .wanted } == my @accepted;
default == my @rejected;
);
somehow. Or even:
@stuff.divvy(
{ .sheep } == my @good;
{ .goats } == my @bad;
default== my @ugly;
);
or maybe the rejected is what is returned:
@stuff.divert(
{ .sheep } == my @good;
{ .goats } == my @bad;
) == my @ugly;
I've put that into parens because I'd like to keep the declarations of
@good and @bad visible. But there's some way to do it with gather and
a switch statement.
my (@good, @bad, @ugly) := gather {
for @stuff {
when .sheep { @good.take($_) }
when .goats { @bad.take($_) }
default { @ugly.take($_) }
}
}
I dunno...at least it emphasizes that the lists are lazily generated...
Anyway, it's not clear to me that grep always has an exact opposite.
Larry
Re: renaming grep to where
On 9/19/06, Larry Wall [EMAIL PROTECTED] wrote:
But which *ect do we call the one that returns both? One would like to
be able to say:
@stuff.direct(
{ .wanted } == my @accepted;
default == my @rejected;
);
Well, sure, but at that point you've moved beyond the realm of
greppish stuff and into more mappish stuff, IMO.
Anyway, it's not clear to me that grep always has an exact opposite.
Standard Larry-disclaimer applies (you've Thought about this a lot
more than I have, but...)
It seems to me that grep takes a list and returns a subset of that
list, so its opposite (along one possible axis of opposition, anyway)
would be something that returns the difference between the original
list and the returned subset. If you're returning something else,
it's no longer grep. (Of course, the block you pass in to grep can
have other side effects, which may not have an opposite, but that's
to me a separate issue).
Also, how is grep intended to work in P6? I had just sort of assumed
that it took any sort of value as a criterion and smart-matched
against it, but pugs currently requires a block...
--
Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf. if ! vs unless). But I'd accept
: filter, too.
Given a choice between 'grep', 'filter', and 'select/reject', I'd
prefer the third model: it counterbalances the break from tradition
with additional functionality.
But which *ect do we call the one that returns both?
In short: if 'select/reject' would be analogous to 'if/unless', should
'select' be allowed the equivalent of an 'else' as well as a 'then'?
Personally, I think that this would be an unneccessary complication -
much like 'unless' doesn't get to split code into true and false
branches, and statement modifiers can't be nested.
Meanwhile, your examples seem to be illustrating another possibility:
something analogous to 'grep' that uses the 'given/when' paradigm
instead of the 'if/then' paradigm. This, I think, has promise -
though, as you say, there's already a way to do this using gather.
What I'd be looking for would be a more compact syntax:
(@good, @bad, @ugly) = @stuff.divvy {
when .sheep { @good }
when .goat { @bad }
default { @ugly }
}
...or something of the sort. Regardless, this oughtn't actually be
the replacement for grep, IMHO; it should _supplement_ grep instead.
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
--
Jonathan Dataweaver Lang
Re: renaming grep to where
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to be the base op and select and reject to be defined as
partition()[1] and partition()[0] respectively...
On 9/19/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf. if ! vs unless). But I'd accept
: filter, too.
Given a choice between 'grep', 'filter', and 'select/reject', I'd
prefer the third model: it counterbalances the break from tradition
with additional functionality.
But which *ect do we call the one that returns both?
In short: if 'select/reject' would be analogous to 'if/unless', should
'select' be allowed the equivalent of an 'else' as well as a 'then'?
Personally, I think that this would be an unneccessary complication -
much like 'unless' doesn't get to split code into true and false
branches, and statement modifiers can't be nested.
Meanwhile, your examples seem to be illustrating another possibility:
something analogous to 'grep' that uses the 'given/when' paradigm
instead of the 'if/then' paradigm. This, I think, has promise -
though, as you say, there's already a way to do this using gather.
What I'd be looking for would be a more compact syntax:
(@good, @bad, @ugly) = @stuff.divvy {
when .sheep { @good }
when .goat { @bad }
default { @ugly }
}
...or something of the sort. Regardless, this oughtn't actually be
the replacement for grep, IMHO; it should _supplement_ grep instead.
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
--
Jonathan Dataweaver Lang
--
Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
Jonathan Lang wrote: Larry Wall wrote: Mark J. Reed wrote: : I have no horse in this race. My personal preference would be to : leave grep as grep. My second choice is select, which to me is : more descriptive than filter; it also readily suggests an antonym of : reject to do a grep -v (cf. if ! vs unless). But I'd accept : filter, too. Given a choice between 'grep', 'filter', and 'select/reject', I'd prefer the third model: it counterbalances the break from tradition with additional functionality. The first thing that I saw in one of Larry's messages about p6 that made me excited about it was the fact that breaking with backward compatibility would mean that we could be rid of the select function that wasn't actually POSIX select. Now, I realize that select in P6 is almost certain to be a method-only, but still... for anyone who has done more than a little POSIX programming, the use of select as a list operator will be jarring as all get-out. This is one of those situations where I find myself asking: what are we trying to solve? Is it the fact that grep is not an English word? Does Perl have to be in English? If grep must die, then I'd suggest filter/reject.
Re: renaming grep to where
On Tue, Sep 19, 2006 at 04:39:35PM -0700, Jonathan Lang wrote: Anyway, it's not clear to me that grep always has an exact opposite. I don't see why it ever wouldn't: you test each item in the list, and the item either passes or fails. 'select' would filter out the items that fail the test, while 'reject' would filter out the ones that pass it. If grep is being kept, and an inverse is also desired, it could be called perg (grep backwards, pronounced purge :-) I'm not serious. Really. --
Re: renaming grep to where
On Tue, Sep 19, 2006 at 07:56:44PM -0400, [EMAIL PROTECTED] wrote: I envision a select, reject, and partition, where @a.partition($foo) Returns the logical equivalent of [EMAIL PROTECTED]($foo), @a.select($foo)] But only executes $foo once per item. In fact. I'd expect partition to be the base op and select and reject to be defined as partition()[1] and partition()[0] respectively... Hmm, that has appeal. If you assign a partition to a list of arrays, 0/false selected go into the first, number goes into the n'th, with the last also getting numbers that are too big and strings that are true. But it could instead be assigned to pairs, and the partition block selects a key or default which chooses the target. --
Re: renaming grep to where
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list operator to
.where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
Trey
Re: renaming grep to where
At 3:36 PM -0700 9/18/06, Trey Harris wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
I suggest that it might be appropriate to rename the .grep list
operator to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
Trey
Either way, the name grep is inferior to various alternatives.
If we are keeping the grep syntax, it should be renamed to some
other, more descriptive word.
It could be where if appropriate, or filter, or something else.
-- Darren Duncan
Re: renaming grep to where
Trey Harris schrieb:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
I generally like words more than sequences of non-word characters as
you can quickly remember/guess the meaning, what's not always the case
when you're reading code (of a language) that you haven't read for a
while. Also you can usually type them more quickly as the word-charactes
have a more prominent position than the special characters on most keybords.
Best Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: renaming grep to where
Darren Duncan wrote:
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list operator
to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
We already have a where keyword in the language, which is used for
very similar things, and I think it would be reasonable that users would
see it used in other situations and think they can use it for filtering
a list too.
I agree with this proposal, although I don't full understand the
implications of using where in this context when it already appears
elsewhere in the language.
Mark
Re: renaming grep to where
We have gone to a great deal of trouble to remove homonyms (such as eval/eval,select/select,do/do/do) from Perl 6, so I would be very unhappy to see us create a new one by re-using where to mean two different things. 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 ;-) 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. Damian
Re: renaming grep to where
At 6:26 AM +0200 9/19/06, Damian Conway wrote: 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. I agree. So filter is now my preference for a new name, and if grep is kept, then that can be an alias for it; filter should be the canonical name for most documentation, though. -- Darren Duncan
Re: Renaming grep
On Nov 19, 2005, at 13:08 , Chip Salzenberg wrote: On Sat, Nov 19, 2005 at 05:46:51AM +0200, Ilmari Vacklin wrote: I don't much like it - it looks like a mistyped 'shift'. Is 'filter' too long? I usually avoid P6L discussions, but: GNU Make has filter and filter-out, and I've always found the polarity hard to remember. I like grep. I like grep, too. FYI google gave me 6,650,000 greps and 4,390,000 sifts. IMHO grep is popular enough. Well, google gave me some 158,000,000 filters but that's rather too common and ambiguous. Note filter does not always sift (i.e. perl - ple '$_=$.:$_'). Dan the (grepp|sift|filter)ed Man
