renaming "grep" to "where"
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.
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
Re: renaming "grep" to "where"
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 written:
@filtered = any(@originals) ~~ { .foo eq $bar};
Trey
Re: renaming "grep" to "where"
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 written:
@filtered = any(@originals) ~~ { .foo eq $bar};
Trey
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
Re: renaming "grep" to "where"
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 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: [EMAIL PROTECTED]
Re: renaming "grep" to "where"
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, 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
[svn:perl6-synopsis] r12185 - doc/trunk/design/syn
Author: larry Date: Mon Sep 18 20:33:07 2006 New Revision: 12185 Modified: doc/trunk/design/syn/S02.pod Log: Some handwaving about type equivalence. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Sep 18 20:33:07 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 13 Sept 2006 + Last Modified: 18 Sept 2006 Number: 2 - Version: 68 + Version: 69 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -346,6 +346,25 @@ =item * +Types are officially compared using name equivalence rather than +structural equivalence. However, we're rather liberal in what we +consider a name. For example, the name includes the version and +authority associated with the module defining the type (even if +the type itself is "anonymous"). Beyond that, when you instantiate +a parametric type, the arguments are considered part of the "long +name" of the resulting type, so one C is equivalent to +another C. (Another way to look at it is that the type +instantiation "factory" is memoized.) Typename aliases are considered +equivalent to the original type. + +This name equivalence of parametric types extends only to parameters +that can be considered immutable (or that at least can have an +immutable snapshot taken of them). Two distinct classes are never +considered equivalent even if they have the same attributes because +classes are not considered immutable. + +=item * + Perl 6 supports the notion of B on various kinds of objects. Properties are like object attributes, except that they're managed by the individual object rather than by the object's class.
Re: renaming "grep" to "where"
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 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
Re: renaming "grep" to "where"
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 "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
Re: renaming "grep" to "where"
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
