renaming "grep" to "where"
Darren Duncan
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.
Moreover, to people who don't come from the Unix command line, or in
general, the term ".where" is more descriptive to what is actually
happening, and as well, it strongly resembles the english statement
for what is happening.
If we want to keep .grep too, it should be an alias, like != is an
alias to !==, but I think letting people use "where" instead would be
a very good thing.
-- Darren Duncan
Trey Harris
> 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
Darren Duncan
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
Thomas Wittek
> > @filtered = @originals.where:{ .foo eq $bar };
>
> Note that this can be written:
>
> @filtered = any(@originals) ~~ { .foo eq $bar};
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: strea...@jabber.i-pobox.net
Mark Stosberg
> 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
Damian Conway
"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
Darren Duncan
>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
Damian Conway
> 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
Smylers
> 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<filter> then when a reader encounters code using C<grep> 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<grep> would continue to use that name in Perl 6, regardless of what
the docs say.
I do not think renaming C<grep> to C<filter> is a terrible idea, but if
it's being done then it should be done properly, not half-heartedly with
an alias.
Smylers
Smylers
> I don't object in principle to renaming "grep" to something more self
> explanatory (except for the further loss of backwards compatability
> and historical Unix reference...though that didn't stop us with
> "switch" vs "given" ;-)
But while C<switch> had precedence in computer science in general it
didn't have this in Perl; your Switch module is not used much in Perl 5,
and Perl 6's C<given> is a substantial improvement over the C<switch>
statement in most languages.
Whereas C<grep> is a well-known and well-used Perl 5 function, and this
functionality is not being changed in Perl 6 (other than being available
as a method as well as a function).
> The standard--and self-explanatory--CS term for this operation has
> always been "filter", which is also currently used by Python, Scheme,
> Haskell, and numerous other languages, so *if* we're going to change
> it from "grep", we ought to change it to "filter".
Yes, but C<grep> is a just one type of filter: it's specifically a
filter on elements in a list. By deploying the generic word "filter"
for this specific use we'd be clobbering its use for any other sorts of
filters -- on lines, source code, coffee, whatever.
I have no statistics but I'd guess that C<filter> is a reasonably common
sub or method name in Perl 5 code found in the wild -- much more so than
C<say> or C<given> -- and that it's currently being used to filter many
things other than lists.
The above are not conclusive reasons why we shouldn't rename C<grep> to
C<filter> (I'm not that bothered either way myself), but just some
points to bear in mind and reasons to be cautious.
Smylers
Jonathan Lang
> Damian Conway writes:
> > I don't object in principle to renaming "grep" to something more self
> > explanatory (except for the further loss of backwards compatability
> > and historical Unix reference...though that didn't stop us with
> > "switch" vs "given" ;-)
>
> But while C<switch> had precedence in computer science in general it
> didn't have this in Perl; your Switch module is not used much in Perl 5,
> and Perl 6's C<given> is a substantial improvement over the C<switch>
> statement in most languages.
>
> Whereas C<grep> is a well-known and well-used Perl 5 function, and this
> functionality is not being changed in Perl 6 (other than being available
> as a method as well as a function).
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
Thomas Wittek
> 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 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
Randal L. Schwartz
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
<mer...@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!
Jonathan Scott Duff
> 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 <du...@pobox.com>
Smylers
> >>>>> "Smylers" == Smylers <Smy...@stripey.com> 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
mark...@mail.com
"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...
--
Mark J. Reed <mark...@mail.com>
Aaron Sherman
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<perl5> aka
:language<perl5> - Perl 5 compat aliases
:os - pull in all OS-specific aliases
:os<posix> - pull in all POSIX aliases
:os<windows> - 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).
Mark J. Reed
> 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.
Aaron Sherman
>> (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".
Mark J. Reed
> 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.
Bob Rogers
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 <du...@pobox.com> 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/
Jonathan Lang
> 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
Mark J. Reed
> 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").
Darren Duncan
> From: mark...@mail.com
> 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 <du...@pobox.com> 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
Darren Duncan
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
Larry Wall
: 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
Mark J. Reed
> 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...
Jonathan Lang
> 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
mark...@mail.com
@a.partition($foo)
Returns the logical equivalent of
[@a.reject($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...
Jonathan Lang
> I envision a select, reject, and partition, where
>
> @a.partition($foo)
>
> Returns the logical equivalent of
>
> [@a.reject($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
[@a.reject(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
Aaron Sherman
> 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.
John Macdonald
> >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.
--
John Macdonald
> I envision a select, reject, and partition, where
>
> @a.partition($foo)
>
> Returns the logical equivalent of
>
> [@a.reject($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.
--
Juerd
> >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 <ju...@juerd.nl> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <sa...@convolution.nl>
Damian Conway
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 { /<[$@%]>/ ?? '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
Aaron Sherman
> 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.
cma...@gmail.com
> 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
mark...@mail.com
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
"select"s, 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".
Aaron Sherman
> 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
> "select"s, 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.
Ben Morrow
Quoth du...@pobox.com:
> 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.'
benm...@tiscali.co.uk
Doug McNutt
$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 <--
Andy Armstrong
> 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
Larry Wall
: 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
Andy Armstrong
> Let it be. :)
I could just as easily have called for a revolution :)
--
Andy Armstrong, hexten.net
Daniel Hulme
> 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'
John Macdonald
> 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. :)
--
Larry Wall
my Yellow sub marine { @we.all.live }
Larry