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