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 C then when a reader encounters code using C 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 C would continue to use that name in Perl 6, regardless of what the docs say. I do not think renaming C to C 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 C 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 is a substantial improvement over the C statement in most languages. Whereas C 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 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 is a reasonably common sub or method name in Perl 5 code found in the wild -- much more so than C or C -- 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 to C (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 C 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 is a substantial improvement over the C statement in most languages. Whereas C 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 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 :compat aka :language - Perl 5 compat aliases :os - pull in all OS-specific aliases :os - pull in all POSIX aliases :os - 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:{ {$_.} };
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:{ };
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"
[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... Can the optimizer handle something like this without too much trouble? If so, I like this. It's expandable: if you allow additional matches to be passed in, it could be made into a switch-like statement: @a.partition( .sheep, .goat) would return the logical equivalent of [EMAIL PROTECTED](any(.sheep, .goat)), @a.select(.sheep), @a.select(.goat)] If you only give it one criterion, this would be equivalent to your version. The main debate I'm having is whether the 'default'/'reject' output should go to element 0 or to the last element; I think that a case could be made that the more intuitive arrangement would be to return the true portion first, followed by the false portion (or, in the multipartition version, the first case first, the second case second, and so on, with whatever's left over going last). -- Jonathan "Dataweaver" Lang
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. --
