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
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?
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
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;
> "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
29 matches
Mail list logo
