On Wed, Sep 20, 2006 at 11:44:49PM -0400, John Macdonald wrote:
: On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
: > On 20 Sep 2006, at 19:05, Larry Wall wrote:
: > >Let it be. :)
: >
: > I could just as easily have called for a revolution :)
:
: No, you should have quoted diffe
On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
> On 20 Sep 2006, at 19:05, Larry Wall wrote:
> >Let it be. :)
>
> I could just as easily have called for a revolution :)
No, you should have quoted differently:
> On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom:
> >
> names they're given. "The Beatles" probably sounded like a really
> dumb name for a band once.
But maybe less dumb than 'The Quarrymen', which was the original name of
the band. (They all went to Quarry Bank school, now Calderstones.)
Perhaps the renaming, unfettered by their history or by a
On 20 Sep 2006, at 19:05, Larry Wall wrote:
Let it be. :)
I could just as easily have called for a revolution :)
--
Andy Armstrong, hexten.net
On Wed, Sep 20, 2006 at 06:54:11PM +0100, Andy Armstrong wrote:
: The Beatles" probably sounded like a really dumb name for a band once.
:
: Is there a serious objection to letting it be?
Let it be. :)
Larry
On 20 Sep 2006, at 18:41, Doug McNutt wrote:
I never thought about the potential for serious ambiguity in
interpretation. The UNIX grep tool is really dissimilar considering
that it uses a different regular expression syntax.
(perl grep doesn't have to be used with an RE of course)
I guess
Just a perl 5 physicist here. I had to run to the Camel book to find out that
grep existed in the world of perl. But I have done this (from memory):
$stuff_in_lines = `grep suntide *.txt`;
I never thought about the potential for serious ambiguity in interpretation.
The UNIX grep tool is really
Quoth [EMAIL PROTECTED]:
> On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote:
> > Jonathan Lang schrieb:
> > > IMHO, syntax should be left alone until a compelling reason to change
> > > it is found. While I think it would be nice to have a more intuitive
> > > name for grep
> > What
[EMAIL PROTECTED] wrote:
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two
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
Aaron (>):
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. "classify" is the real grep
2. convenience function, "keep" is probably a macro
3. "use List :compat" will get you a "grep" just as it wil
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a "label" value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that labe
Just to point out that it's probably worth going back and rereading the
earlier iterations of this discussion, in December 2002 (subject: "purge: the
opposite of grep") and November 2005 (subject: "Classification syntax"). That
way, those who repeat history are condemned to study it. ;-)
In su
Jonathan Lang skribis 2006-09-19 16:39 (-0700):
> >Anyway, it's not clear to me that grep always has an exact opposite.
> I don't see why it ever wouldn't: you test each item in the list, and
> the item either passes or fails. 'select' would filter out the items
> that fail the test, while 'reject
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 partit
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 t
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 -
[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
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 part
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 "unl
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
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 -
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 h
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 enamor
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, un
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 b
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
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
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 definiti
(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 happ
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 o
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 Tu
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
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.
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
> "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.stoneheng
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 t
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 precedenc
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
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 sc
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 al
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
At 6:26 AM +0200 9/19/06, Damian Conway wrote:
The standard--and self-explanatory--CS term for this operation has
always been "filter", which is also currently used by Python, Scheme,
Haskell, and numerous other languages, so *if* we're going to change
it from "grep", we ought to change it to "fi
We have gone to a great deal of trouble to remove homonyms (such as
"eval"/"eval","select"/"select","do"/"do"/"do") from Perl 6, so I
would be very unhappy to see us create a new one by re-using "where"
to mean two different things.
I don't object in principle to renaming "grep" to something more
Darren Duncan wrote:
> Putting aside legacy issues for the moment,
>
> I suggest that it might be appropriate to rename the .grep list operator
> to .where, so we can say, for example:
>
> @filtered = @originals.where:{ .foo eq $bar };
>
> We already have a "where" keyword in the language, whi
Trey Harris schrieb:
> > @filtered = @originals.where:{ .foo eq $bar };
>
> Note that this can be written:
>
>@filtered = any(@originals) ~~ { .foo eq $bar};
I generally like "words" more than sequences of non-word characters as
you can quickly remember/guess the meaning, what's not always the
At 3:36 PM -0700 9/18/06, Trey Harris wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
I suggest that it might be appropriate to rename the .grep list
operator to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be writte
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list operator to
.where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be writt
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 thing
49 matches
Mail list logo
