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!
class interface of roles
HaloO,
After re-reading about the typing of mixins in
http://www.jot.fm/issues/issue_2004_11/column1
I wonder how the example would look like in Perl6.
Here is what I think it could look like:
role GenEqual
{
method equal( : GenEqual $ -- Bool ) {...}
}
role GenPointMixin
{
has Int $.x;
has Int $.y;
method equal( ::?CLASS GenEqual $self: ::?CLASS $p -- Bool )
{
return super.equal(p) and # -- handwave
self.x == $p.x and self.y == $p.y;
}
}
class GenSquare does GenEqual does GenPointMixin
{
has Int $.side;
method equal ( : ::?CLASS $p -- Bool )
{
return self.side == $p.side;
}
}
The handwave part is the interface of the composed role to
the class it is composed into and the typing of this interface.
The article proposes to expand the mixin self type prior to the
class interface. The latter then poses type constraints onto the
class. Do roles work like that in Perl6? I mean would the approach
of the article of using two F-bounded quantifications (see the last
formular in section 8) be a valid type model for class composition?
Regards, TSa.
--
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]
Threads and types
What happens to a program that creates a thread with a shared variable between it and the parent, and then the parent modifies the class from which the variable derives? Does the shared variable pick up the type change? Does the thread see this change?
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. --
