Re: purge: opposite of grep
Damian Conway writes:
> Famous last words. ;-)
>
>
> > Was it ever decided what C would look like with multiple streams?
>
> for zip(@x, @y, @z) -> $x, $y, $z {...}
>
> and its operator version:
>
> for @x ¦ @y ¦ @z -> $x, $y, $z {...}
>
>
> > Maybe we could just use the stream delimiters in the C like we do
> > in C?
>
> No. We gave up special stream delimiters in Cs,
> in preference for general zippers.
>
> Damian
>
but one can think of zip(...) being able to be l-value
@x ¦ @y ¦ @z := map { /foo/ && $_ but unzip(0),
/bar/ && $_ but unzip(1),
/zap/ && $_ but unzip(2),
}, @source;
where argument of unzip is index of the stream to which to "direct"
the value . but then I am not sure where the actual "nzipping" happens
and what does it mean binding to the l-value function.
arcadi
Re: purge: opposite of grep
Brent Dax wrote:
It just occurred to me that C is almost a specialization of
C. Consider the results if you assign without binding:
sub comparator {
when /hi/ { 0 }
when /lo/ { 1 }
default { 2 }
}
@input = qw(high low hi lo glurgl);
@out1 = part comparator @input;
@out2 = sort { comparator $^a <=> comparator $^b } @input;
Identical, aren't they?
No.
@out1 has three elements, each an array reference: (['high','hi'], ['low','lo'], ['glurgl'])
@out2 has five elements, each a string: ('high', 'hi', 'low', 'lo', 'glurgl')
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Hm. Sound more like:
--Damian Conway, explaining how Perl 6 junctions came to be
;-)
Damian
Re: 'hashkey context/Str context' (was Re: purge: opposite of grep)
Dave Storrs wrote: My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? Not wrong. But it's not the default. The default is Str keys only. But I take your point and it may well be that C is a useful think to know. Damian
Re: purge: opposite of grep
Ken Fox wrote:
> Sometimes array references behave as arrays, e.g.
>
> push $array, 1
>
> In flattening context array refs don't flatten, only arrays.
> I'm not even sure that only arrays flatten either -- it might
> be anything that begins with @. e.g.
>
> my Point @p;
> ($x, $y) := @p;
>
> If the flattening rule is "only @ symbols flatten" then it
> would be lexical flattening -- we only have to look at the
> text. (I'm using lexical in the same sense as lexical
> variable uses it.)
That would certainly make sense.
> It would actually be nice if all the C, C,
> etc. functions became methods, e.g.
>
> push @array: 1;
I'm undecided on that. I can certainly see the appeal though.
>> Depends on your definition of simpler, I guess.
>
> I don't see anything particularly complex about this:
>
>my $index = 0;
>for @classifiers {
>return $index if $_.($nextval);
>++$index
>}
Apart from the fact that it creates a gratuitous lexical outside
the scope of the C block. And that it requires explicit vs
implicit incrementing of the index variable. And it won't work if
the array doesn't start at index 0, or doesn't have contiguous
indices.
Whereas:
for @classifiers.kv -> $index, $_ {
return $index if $_.($nextval);
}
suffers from none of those problems. And has half as many lines.
And encourages the coder to name the topic something more maintainable:
for @classifiers.kv -> $index, &classifier {
return $index if classifier($nextval);
}
> That's understandable and it should produce simple bytecode.
We're probably not going to convince each other.
I guess it's a religious issue. ;-)
> Yes, I agree, but it needs to construct a stream generator
> which isn't particularly efficient.
I suspect that .kv iterators will be *very* lightweight.
Precisely because they will be heavily used for this very idiom.
> I was surprised to see it
> in a place where the generality and elegance isn't needed.
IMHO there is *no* such place. ;-)
> Thanks for the explanation of the junction. I'm not sure
> whether I'm more excited by the possibility to write code
> using junctions or more terrified by the certainty of
> debugging that code... ;)
Well, I'd hope you'd be *both*!
> How about formalizing global namespace pollution with something
> like the Usenet news group formation process? Ship Perl 6 with a
> very small number of global symbols and let it grow naturally.
I'm not in favour of that. Most of the things we're having to
fix in Perl 6 are things that "grew naturally" in Perl 5.
Evolution is *greatly* overrated.
Damian
Re: purge: opposite of grep
Smylers wrote: If the initial release of Perl 6 doesn't have commonly-required functions then people will write their own. People will do these in incompatible ways, ensuring that when it's determined that the language would benefit from having a particular function built in at least some people will have to change their code to keep it working. People will also choose different names for their functions. If C only appears in Perl version 6.0.3, there'll already be dozens of scripts which have a sub of that name doing something completely different. Adding extra functions will create critical differences between versions of Perl with very small differences in their version number. People will get frustrated at needing a particular point-release of Perl to run programs[*0]. Or, alternatively, people will shy away from using those functions -- which by definition are so useful in every day programming that it's been decided to add them to the language -- because they want their code to be portable, thereby defeating the purpose of adding them. Perl 6.0.0 can't be perfect, but please can we aim to be as close as possible. Releasing a language with the caveat "but we've missed out lots of important functions that we expect to add in the next version or four" strikes me as a little odd. Amen! I deliberately requoted all of that because it's so very right that I wanted everyone to reread it. ;-) I have nothing to add except my wholehearted agreement, and a reminder of how much trouble was caused in Perl 5 by not having one form of switch statement, and therefore ending up with 23 forms of switch statement. Damian
Re: purge: opposite of grep
At 8:07 PM + 12/9/02, Smylers wrote: Perl 6.0.0 can't be perfect, but please can we aim to be as close as possible. Releasing a language with the caveat "but we've missed out lots of important functions that we expect to add in the next version or four" strikes me as a little odd. I think we're better off shooting for 6.0.0 not getting in the way in spots we're not sure of, rather than perfection. We can fix an awful lot later if we don't get in our own way now. I fully expect that the keyword list will be closed off for rather a long time, though, once 6.0.0 has been released, so perhaps energy would be better directed in figuring out how to make something like purge (and its syntactic cousins) work as an add-on? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 'hashkey context/Str context' (was Re: purge: opposite of grep)
> Date: Sun, 8 Dec 2002 21:52:33 -0800 > From: Dave Storrs <[EMAIL PROTECTED]> > > On Sat, Dec 07, 2002 at 01:28:41PM +1100, Damian Conway wrote: > > Dave Whipp wrote: > > > > > I notice everyone still want Int context for eval of the block: > > > Pease don't forget about hashes. Is there such a thing as > > > 'hashkey context'? > > > > I doubt it. Unless you count Str context. > > My understanding was that in Perl6, you could use pretty much anything > for a hashkey--string, number, object, whatever, and that it did not > get mashed down into a string. Did I have this wrong? By default they're keyed by strings. You can smack a property on them to key them by something else, though: my %sparse is keyed(Int); my %anything is keyed(Object); # or UNIVERSAL Luke
Re: purge: opposite of grep
Ken Fox wrote: > If C is not a method or multimethod, then it acts like a > reserved word or built-in, like C or C. IMHO that's name > space pollution. Yes, it is namespace pollution, but I don't think that's a problem in Perl. Many other languages have functions in the same namespace as variables; this is usually the biggest problem, since people tend to have more variables than functions. Perl's sigils means this isn't a problem: C<$part> or C<@part> cannot conflict with C. Functions are all in a namespace. Perl providing C doesn't preclude the existence of C or whatever. Most core functions can be overridden, so even if you don't like the built-in behaviour you can change it, without Perl insisting on keeping the original name for itself. Perl 5 doesn't permit this with all built-in functions, but I'm hoping that the improved grammar and function declaration syntax in Perl 6 will allow many more built-in functions to be overridden. > How about formalizing global namespace pollution with something like > the Usenet news group formation process? Ship Perl 6 with a very > small number of global symbols and let it grow naturally. If the initial release of Perl 6 doesn't have commonly-required functions then people will write their own. People will do these in incompatible ways, ensuring that when it's determined that the language would benefit from having a particular function built in at least some people will have to change their code to keep it working. People will also choose different names for their functions. If C only appears in Perl version 6.0.3, there'll already be dozens of scripts which have a sub of that name doing something completely different. Adding extra functions will create critical differences between versions of Perl with very small differences in their version number. People will get frustrated at needing a particular point-release of Perl to run programs[*0]. Or, alternatively, people will shy away from using those functions -- which by definition are so useful in every day programming that it's been decided to add them to the language -- because they want their code to be portable, thereby defeating the purpose of adding them. Perl 6.0.0 can't be perfect, but please can we aim to be as close as possible. Releasing a language with the caveat "but we've missed out lots of important functions that we expect to add in the next version or four" strikes me as a little odd. [*0] Yes, obviously this always applies to some extent: a point-release wouldn't be made unless it adds or changes _something_ in the language. But often these are small things, or tweaks to edge-case behaviour. Smylers
'hashkey context/Str context' (was Re: purge: opposite of grep)
On Sat, Dec 07, 2002 at 01:28:41PM +1100, Damian Conway wrote: > Dave Whipp wrote: > > > I notice everyone still want Int context for eval of the block: > > Pease don't forget about hashes. Is there such a thing as > > 'hashkey context'? > > I doubt it. Unless you count Str context. My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? --Dks
RE: purge: opposite of grep
It just occurred to me that C is almost a specialization of
C. Consider the results if you assign without binding:
sub comparator {
when /hi/ { 0 }
when /lo/ { 1 }
default { 2 }
}
@input = qw(high low hi lo glurgl);
@out1 = part comparator @input;
@out2 = sort { comparator $^a <=> comparator $^b } @input;
Identical, aren't they? If C returned all items that evaluated to
0 (equal) together, they would be identical when bound, too. (Of
course, how such a thing would be implemented or even expressed as an
exercise for the reader. :^) )
[ It seems that this thread has drifted off-topic. Perhaps a renaming
is in order? ]
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: purge: opposite of grep
Damian Conway wrote:
Ken Fox asked:
Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
I'm not sure I understand this question.
Sometimes array references behave as arrays, e.g.
push $array, 1
In flattening context array refs don't flatten, only arrays.
I'm not even sure that only arrays flatten either -- it might
be anything that begins with @. e.g.
my Point @p;
($x, $y) := @p;
If the flattening rule is "only @ symbols flatten" then it
would be lexical flattening -- we only have to look at the
text. (I'm using lexical in the same sense as lexical
variable uses it.)
Multimethods don't belong to any particular class.
Does it *need* to be a method or multimethod???
If C is not a method or multimethod, then it acts
like a reserved word or built-in, like C or C.
IMHO that's name space pollution.
I know multi-methods don't "belong" to a class. It seems
useful to develop standards on where the implementation
is found though. I would expect to find C as an
auto-loaded multimethod in "perl6/6.0/auto/array/part.al"
It would actually be nice if all the C, C,
etc. functions became methods, e.g.
push @array: 1;
Depends on your definition of simpler, I guess.
I don't see anything particularly complex about this:
my $index = 0;
for @classifiers {
return $index if $_.($nextval);
++$index
}
That's understandable and it should produce simple bytecode.
If @classifiers is sparse or non-zero-based, then the .kv
method might be better.
I really think an C method nicely meets the very common need of
iterating the indices and values of an array in parallel, with a minimum
of syntax and a maximum of maintainability.
Yes, I agree, but it needs to construct a stream generator
which isn't particularly efficient. I was surprised to see it
in a place where the generality and elegance isn't needed.
Thanks for the explanation of the junction. I'm not sure
whether I'm more excited by the possibility to write code
using junctions or more terrified by the certainty of
debugging that code... ;)
And I'm suggesting that Cing is such sweet sorrow that everyone
will want to do it all the time. Or at least often enough that dragging
it in from a module with rapidly become a PITA. Just as it in Perl 5
to use C or C.
How about formalizing global namespace pollution with something
like the Usenet news group formation process? Ship Perl 6 with a
very small number of global symbols and let it grow naturally.
- Ken
Re: purge: opposite of grep
David Wheeler wrote: Ooh, I like C best. C is too easy to interpret as other things (partition? part with? part from? part of? partner? etc.). You know, that's *exactly* why I like C better. ;-) Damian
Re: purge: opposite of grep
Ken Fox asked:
sub part ($classifier, *@list) {
return @parts;
}
Given the original example
(@foo,@bar,@zap) := part [ /foo/, /bar/, /zap/ ] @source;
this binds the contents of @parts to (@foo,@bar,@zap)?
Yes.
The array refs in @parts are not flattened though.
Correct. Each array ref is bound to the corresponding array name.
>
Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
I'm not sure I understand this question.
BTW, if part were declared as an array method, the syntax
becomes
@source.part [ /foo/, /bar/, /zap/ ]
Nearly. The parens are not optional on this form of method call, I believe.
So that would be:
@source.part([ /foo/, /bar/, /zap/ ]);
or
part @source: [ /foo/, /bar/, /zap/ ]
Yes.
Can part be a multi-method defined in the array class
Multimethods don't belong to any particular class.
Does it *need* to be a method or multimethod???
for @classifiers.kv -> $index, &test {
An array::kv method? Very useful for sparse arrays, but
is this preferred for all arrays? An explicit index counter
seems simpler in this case.
Depends on your definition of simpler, I guess. Depending on what you mean by
"explicit index counter", that would have to be:
for [EMAIL PROTECTED] ¦ @classifiers -> $index, &test {
...
}
Or (heaven forefend!):
loop (my $index=0; $index<@classifiers; $index++) {
my &test := @classifiers[$index];
...
}
I really think an C method nicely meets the very common need of
iterating the indices and values of an array in parallel, with a minimum
of syntax and a maximum of maintainability.
my @indices = map { defined .key()($nextval) ?? .value
:: () } %classifiers;
That map body looks like a syntax error, but it isn't.
> Can I add extra syntax like
map { defined(.key.($nextval)) ?? .value :: () }
to emphasize the fact that .key is returning a code ref?
Yes, indeed.
Last, but not least, the Hash case returns a junction (most
likely of a single value). Junctions don't collapse like
superpositions, so I'm wondering what really happens.
Can you describe the evaluation?
Sure. Suppose that the classifier closure returns the junction C.
Then, within C, the C<$index> variable stores that junction (i.e. junctions
survive both a copy-on-return and an assignment). The next statement is:
push @parts[$index], $nextval;
The use of a junction as an index causes the array look-up to return a junction
of aliases to the array elements selected by the various states of the index.
So C<@parts[$index]> is a disjunction of a single alias (i.e. to C<@parts[1]>).
Pushing the next value onto that alias causes it to autovivify as an array ref
(if necessary), and then push onto that nested array.
Suppose instead that the classifier closure returns the junction C.
Then, within C, the C<$index> variable stores that junction, and its use
as an index causes the array look-up to return a junction
of aliases to the array elements selected by the two states of the index.
So C<@parts[$index]> is, in this second case, a disjunction of two aliases
(i.e. to C<@parts[0]> and C<@parts[1]>). Pushing the next value onto that
disjunctive alias causes it to autovivify both elements as array refs
(if necessary), and then -- in parallel -- push the value onto each nested array.
I'm really interested in how
long the junction lasts (how quickly it turns into an integer
index),
It never turns into an integer index. Using a junction as an index is the
same as passing it to the C method, which causes the
call to the method to be distributed over each state in the junction. So, just
as:
foo(1|2|3)
is the same as:
foo(1) | foo(2) | foo(3)
so:
@array[1|2|3]
is the same as:
@array[1] | @array[2] | @array[3]
And:
@array[1|2|3] = "str";
is the same as:
(@array[1] | @array[2] | @array[3]) = "str"
which the same as:
(@array[1] = "str") | (@array[2] = "str") | (@array[3]) = "str")
and what happens with a duplicate (ambiguous?) index.
Can't happen. As Luke has expounded, junctions are a form of set,
and have no duplicate states.
Perhaps the part method can be implemented as a mix-in module that
extends array without subclassing it?
And I'm suggesting that Cing is such sweet sorrow that everyone
will want to do it all the time. Or at least often enough that dragging
it in from a module with rapidly become a PITA. Just as it in Perl 5
to use C or C.
Manipulating a core data type in commonly useful ways ought to be via
core operations (or, at worst, operations that are invisibly non-core),
so that JAPHs are encouraged to code what they mean explicitly:
$sum = reduce {$^a+$^b} @nums;
$max = max @nums;
rather than emergently:
my ($max, $sum) = (-Inf, -Inf);
for @nums {
$max = $_ if $max < $_;
$sum += $_;
}
AUTOLOAD can do that now
for packages
Re: purge: opposite of grep
On Sunday, December 8, 2002, at 10:20 AM, Smylers wrote: I dislike C cos it's a small typo away from C. Yes, but I would expect to be a compile-time error, since the signatures are different. The same can't be said for r?index. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: purge: opposite of grep
David Wheeler wrote: > On Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: > > > Ian Remmler decloaked and wrote: > > > > > I keep thinking C would be nice ... > > > > C is quite good. Though I still like C best. > > Ooh, I like C best. I dislike C cos it's a small typo away from C. Smylers
Re: purge: opposite of grep
On Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: I keep thinking C would be nice, or maybe C. Just a thought... C is quite good. Though I still like C best. Ooh, I like C best. C is too easy to interpret as other things (partition? part with? part from? part of? partner? etc.). David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: purge: opposite of grep
Damian Conway wrote:
sub part ($classifier, *@list) {
return @parts;
}
Given the original example
(@foo,@bar,@zap) := part [ /foo/, /bar/, /zap/ ] @source;
this binds the contents of @parts to (@foo,@bar,@zap)? The
array refs in @parts are not flattened though. Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
BTW, if part were declared as an array method, the syntax
becomes
@source.part [ /foo/, /bar/, /zap/ ]
or
part @source: [ /foo/, /bar/, /zap/ ]
Can part be a multi-method defined in the array class
so the original example syntax can be used? (I'd prefer
the code too because the switch statement is eliminated.)
sub convert_to_sub ($classifier is topic) is cached {
Very nice.
for @classifiers.kv -> $index, &test {
An array::kv method? Very useful for sparse arrays, but
is this preferred for all arrays? An explicit index counter
seems simpler in this case.
my @indices = map { defined .key()($nextval) ?? .value
:: () } %classifiers;
That map body looks like a syntax error, but it isn't. Can I add
extra syntax like
map { defined(.key.($nextval)) ?? .value :: () }
to emphasize the fact that .key is returning a code ref?
Last, but not least, the Hash case returns a junction (most
likely of a single value). Junctions don't collapse like
superpositions, so I'm wondering what really happens.
Can you describe the evaluation? I'm really interested in how
long the junction lasts (how quickly it turns into an integer
index), and what happens with a duplicate (ambiguous?) index.
Sorry for so many questions. The code you wrote was just a
really, really good example of many Perl 6 features coming
together.
[This is out of order; Damian wrote it in another message.]
> Everything doesn't. Everything shouldn't be. Just the really common,
> important stuff.
So CGI.pm is in?
I don't think "really common, important" is a good criteria for
being in the core. IMHO it should be "language defining, awkward or
impossible to implement as a module".
Perhaps the part method can be implemented as a mix-in module that
extends array without subclassing it? AUTOLOAD can do that now
for packages. Are classes sealed or will they use AUTOLOAD too?
- Ken
Re: purge: opposite of grep
On Sun, Dec 08, 2002 at 11:28:24AM +1100, Damian Conway wrote: > We could certainly do that. But let's call it C. I usually just lurk here, but I just had to pipe in. :) I'm not sure the meaning of the name C would be obvious to someone who hadn't seen it before. I keep thinking C would be nice, or maybe C. Just a thought... - Ian.
Re: purge: opposite of grep
[EMAIL PROTECTED] (Damian Conway) writes: > Of course, as long as you can call C without explicitly loading > a module, it's merely a philosophical distinction as to whether > C is core or not. Well, no; it's an implementation distinction too. Non-core methods 1) don't mean anything special to the compiler 2) can be implemented in C, Perl, Parrot, or whatever else we like and 3) can be added or taken away without affecting the basic design of the language all of which means 4) we don't have to worry about them quite yet. Although the concept of having a data type called an array is core to the design of Perl 6, the precise clever methods those arrays respond to can be added organically later, or even customized by the end-user. Basically, I'm just saying that we don't have to put everything in at once. Let's have finish carving the statue before we decide what shade of vermillion to paint its toenails. -- >Almost any animal is capable learning a stimulus/response association, >given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: purge: opposite of grep
Ian Remmler decloaked and wrote: I'm not sure the meaning of the name C would be obvious > to someone who hadn't seen it before. What, as opposed to C or C or C or C or C or C or C or C or C or C or C or C or C or...? ;-) I keep thinking C would be nice, or maybe C. Just a thought... C is quite good. Though I still like C best. Damian
Re: purge: opposite of grep
Michael Lazzaro wrote:
If we're worried about the distance between the source and destination
when there are many tests
Are we? I'm not.
maybe:
part { /foo/ => @foo, /bar/ => @bar, /zap/ => @zap }, @source;
Or, 'long' formatted:
part {
/foo/ => @foo,
/bar/ => @bar,
/zap/ => @zap,
}, @source;
I really dislike the use of dative arguments (i.e. those that are modified
in-place by a function).
Besides, you can already write:
push (
/foo/ ?? @foo ::
/bar/ ?? @bar ::
/baz/ ?? @baz ::
[]
), $_ for @source;
Heck, even in Perl 5 you can write:
push @{
/foo/ ? \@foo :
/bar/ ? \@bar :
/baz/ ? \@baz :
[]
}, $_ for @source;
I keep thinking we're missing something here. This is just a
multi-streamed C, after all. It should be easy.
Famous last words. ;-)
Was it ever decided what C would look like with multiple streams?
for zip(@x, @y, @z) -> $x, $y, $z {...}
and its operator version:
for @x ¦ @y ¦ @z -> $x, $y, $z {...}
Maybe we could just use the stream delimiters in the C like we do
in C?
No. We gave up special stream delimiters in Cs,
in preference for general zippers.
Damian
Re: purge: opposite of grep
Damian Conway wrote:
> (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source;
If we're worried about the distance between the source and destination
when there are many tests, maybe:
part { /foo/ => @foo, /bar/ => @bar, /zap/ => @zap }, @source;
Or, 'long' formatted:
part {
/foo/ => @foo,
/bar/ => @bar,
/zap/ => @zap,
}, @source;
Assuming the type system can handle that. But people will forget the
comma before C<@source>, because it looks so similar to C. And
think of the { ... } as a code block, not a hashref. Pffft.
I keep thinking we're missing something here. This is just a
multi-streamed C, after all. It should be easy.
Was it ever decided what C would look like with multiple streams?
Maybe we could just use the stream delimiters in the C like we do
in C?
grep {
/foo/ -> @foo,
/bar/ -> @bar,
/zap/ -> @zap,
} @source;
???
MikeL
Re: purge: opposite of grep
ralph wrote:
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
True.
Why not:
part ( @source, /foo/ => @foo, /bar/ => @bar, /zap/ => @zap );
Because C, C, C etc all take the list they're
operating on as the last argument. And they do that for a very good reason:
so it's easy to build up more complex right-to-left pipelines, like:
(@foo, @bar) :=
part [/foo/, /bar/],
sort { $^b <=> $^a }
grep { $_ > 0 }
@data;
@source -> /foo/ => @foo, /bar/ => @bar, /zap/ => @zap;
Huh???
That's the equivalent of:
@source, sub (/foo/ => @foo, /bar/ => @bar, /zap/ => @zap);
which is just a syntax error.
To end up with @foo entries being *aliases* of
entries in @source. Btw, could these be valid,
Err. I very much doubt it.
Damian
Re: purge: opposite of grep
Simon Cozens wrote: A categorise method would be just grand, and I think it should be shipped with the default Perl 6 array classes, but Perl 6 The Core Language wouldn't need to know about that particular method if it didn't want to. Err. Since arrays are core to Perl 6, how could their methods not be? Of course, as long as you can call C without explicitly loading a module, it's merely a philosophical distinction as to whether C is core or not. Damian
Re: purge: opposite of grep
> push (/foo/ && @foo ||
> /bar/ && @bar ||
> /zap/ && @zap), $_ for @source;
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
> But perhaps...
>
> ( @foo, @bar, @zap) :=
> part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
Why not:
part ( @source, /foo/ => @foo, /bar/ => @bar, /zap/ => @zap );
or maybe:
@source -> /foo/ => @foo, /bar/ => @bar, /zap/ => @zap;
To end up with @foo entries being *aliases* of
entries in @source. Btw, could these be valid,
and if so, what might they do:
@source -> $foo, $bar;
@source -> @foo, @bar;
--
ralph
Re: purge: opposite of grep
[EMAIL PROTECTED] (Damian Conway) writes: > > Why does everything have to be built into the first version of Perl 6? > > Everything doesn't. Everything shouldn't be. Just the really common, > important stuff. > > I have to confess though, there are *many* times I've wished for > this particular functionality as a built-in. Which is why I'm > spending time on it now. This may be a useful distinction: stuff which is built into the language versus stuff which is shipped in the default libraries of the language. A categorise method would be just grand, and I think it should be shipped with the default Perl 6 array classes, but Perl 6 The Core Language wouldn't need to know about that particular method if it didn't want to. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: purge: opposite of grep
Damian Conway wrote:
Et voilà:
Or, of those who prefer their code sanely formatted:
sub part ($classifier, *@list) {
my &classify := convert_to_sub($classifier);
my @parts;
for @list -> $nextval {
my $index = try{ classify($nextval) } // next;
push @parts[$index], $nextval;
}
return @parts;
}
sub convert_to_sub ($classifier is topic) is cached {
when Code { return $classifier }
when Array {
my @classifiers = map {convert_to_code($_)} @$classifier;
return sub ($nextval) {
for @classifiers.kv -> $index, &test {
return $index if test($nextval);
}
return;
}
}
when Hash {
my %classifiers = map { convert_to_code(.key) => .value } %$classifier;
return sub ($nextval) {
my @indices = map { defined .key()($nextval) ?? .value :: () } %classifiers;
return @indices ?? any(@indices) :: undef;
}
}
default{ croak "Invalid classifier (must be closure, array, or hash)" }
}
Damian
Re: purge: opposite of grep
Ken Fox asked:
How about just
(@foo,@bar,@zap) := classify [ rx/foo/, rx/bar/, rx/zap/ ] @source;
and implement classify as a normal sub?
We could certainly do that. But let's call it C.
Et voilà:
sub part ($classifier, *@list) {
my &classify := convert_to_sub($classifier);
my @parts;
for @list -> $nextval {
my $index = try{ classify($nextval) } // next;
push @parts[$index], $nextval;
}
return @parts;
}
sub convert_to_sub ($classifier is topic) is cached {
when Code { return $classifier }
when Array {
my @classifiers = map {convert_to_code($_)} @$classifier;
return sub ($nextval) {
for @classifiers.kv -> $index, &test {
return $index if test($nextval);
}
return;
}
}
when Hash {
my %classifiers = map { convert_to_code(.key) => .value } %$classifier;
return sub ($nextval) {
my @indices = map { defined .key()($nextval) ?? .value :: () } %classifiers;
return @indices ?? any(@indices) :: undef;
}
}
default{ croak "Invalid classifier (must be closure, array, or hash)" }
}
But then the thousands of people who are apparently clamouring for this
functionality and who would have no hope of getting the above correct,
would have to pull in some module every time they wanted to partition an array.
> Why does everything have to be built into the first version of Perl 6?
Everything doesn't. Everything shouldn't be. Just the really common,
important stuff.
I have to confess though, there are *many* times I've wished for this particular
functionality as a built-in. Which is why I'm spending time on it now.
Damian
Re: purge: opposite of grep
> Damian Conway wrote: > > or even a arrayed form, when the corresponding index was implicit: > > > > (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source; > > That's kinda nifty. But admittedly, it's not to-die-for necessary, if > I'm the only one fond of it. I think this makes a nice specialization of the hash approach. However, I believe it will become cumbersome with anything other than trivial expressions. The hash approach, in that case, would be clearer. Tanton
Re: purge: opposite of grep
Damian Conway wrote: > or even a arrayed form, when the corresponding index was implicit: > > (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source; That's kinda nifty. But admittedly, it's not to-die-for necessary, if I'm the only one fond of it. Ken Fox wrote: > and implement classify as a normal sub? Why does everything > have to be built into the first version of Perl 6? Yeah, I agree! Oh, except when it's things _I'm_ asking for. _Those_ are always 100% necessary. :-/ (We're basically asking for everything under the sun, but I think we all know that < 10% of it will actually get in, which is a Good Thing. :-) But sometimes the brainstorming shakes loose something more broadly interesting.) MikeL P.S. As for judging the value of a proposal, I personally try to ask the following questions: 1) Is it a simplification of a universally common but otherwise long/tedious algorithm? 2) Is there only One Way To Do It (Correctly)? 3) Is there a name for the operation so obvious that you can, after being first introduced to it, easily remember what it does? (like "reverse", "split", "while", etc.) Not that I always take my own advice. :-) Other people might have different informal criteria. (For future teaching purposes, I'd love to hear what they are.)
Re: purge: opposite of grep
Michael Lazzaro wrote:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
A shorthand for:
for @source {
given {
when /foo/ { push @foo, $_ }
when /bar/ { push @bar, $_ }
when /zap/ { push @zap, $_ }
}
}
How about just
(@foo,@bar,@zap) := classify [ rx/foo/, rx/bar/, rx/zap/ ] @source;
and implement classify as a normal sub? Why does everything
have to be built into the first version of Perl 6?
Is there any reason classify can't be a normal sub? e.g. can
a sub return ( [], [], [] ) and have that bound to 3 array
variables? What about return @AoA when @AoA = ( [], [], [] )?
- Ken
Re: purge: opposite of grep
Michael Lazzaro wrote:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
A shorthand ... that "classifies" (or "parts") @source according to
> the results of a series of tests, not just one.
You mean, like:
(@foo,@bar,@zap) := part { when /foo/ {0}; when /bar/ {1}; when /zap/ {2} } @source;
???
And there's always:
push (/foo/ && @foo || /bar/ && @bar || /zap/ && @zap), $_ for @source;
But perhaps there would also be a hashed form, in which each key is a test
(i.e. a rule or closure) and each value an index:
(@foo,@bar,@zap) := part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
or even a arrayed form, when the corresponding index was implicit:
(@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source;
Damian
Re: purge: opposite of grep
Damian Conway wrote:
>
> Michael Lazzaro wrote:
>
> > How would you do something like:
> >
> > (@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
>
> Since I don't understand what that's supposed to do, I probably *wouldn't*
> do something like it. What effect are you trying to achieve?
Sorry. A shorthand for:
for @source {
given {
when /foo/ { push @foo, $_ }
when /bar/ { push @bar, $_ }
when /zap/ { push @zap, $_ }
}
}
that "classifies" (or "parts") @source according to the results of a
series of tests, not just one.
MikeL
RE: purge: opposite of grep
Damian Conway:
# > Also, can I return superpositions (sorry, junctions), to provide
# > multiple classifications? Or would I return an array for that?
#
# A (dis)junction ought to work there.
That sounds horribly scary...
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: purge: opposite of grep
Michael Lazzaro wrote:
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
Since I don't understand what that's supposed to do, I probably *wouldn't*
do something like it. What effect are you trying to achieve?
Damian
Re: purge: opposite of grep
Dave Whipp wrote:
I notice everyone still want Int context for eval of the block:
Pease don't forget about hashes. Is there such a thing as
'hashkey context'?
I doubt it. Unless you count Str context.
Perl6 is much better than Perl5 for naming parameters. Could
we make the following work?
( low=>@under,
mid=>@in_range,
high=>@over )
= partition @input -> $v {
$v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid";
};
I very much doubt it. I think at that point you really want:
for @input -> $v {
push ($v < 10 ?? @under :: $v > 20 ?? @over :: @in_range), $v;
}
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
A (dis)junction ought to work there.
Damian
Re: purge: opposite of grep
ralph wrote:
I worry that C sounds too much like
something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
ralph and I don't often agree, but I certainly do in this case.
I like C very much as a name for this built-in. Must be
the vaguely biblical association ;-)
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
Sure. It means that the key of the pair is an array reference.
Damian
Re: purge: opposite of grep
Sean O'Rourke writes:
> On Thu, 5 Dec 2002, Sean O'Rourke wrote:
> > how 'bout "tang" for "Tog's A Negated Grep"?
>
> Gah. s/Tog/Tang/.
Wouldn't that mean we had to rename grep to 'gnat'? ("Gnat's Not A Tang",
presumably, never mind rot13 and reversal...)
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: > On 5 Dec 2002, Rafael Garcia-Suarez wrote: > > John Williams wrote in perl.perl6.language : > > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > > ex(1) / vi(1) commands (where 're' stands for regular expression, of > > course) : > > :g/re/p > > :v/re/p > > Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" > for "Elide REgex" or "tang" for "Tog's A Negated Grep"? Gah. s/Tog/Tang/. /s
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > John Williams wrote in perl.perl6.language : > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > ex(1) / vi(1) commands (where 're' stands for regular expression, of > course) : > :g/re/p > :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" for "Elide REgex" or "tang" for "Tog's A Negated Grep"? /s
Re: purge: opposite of grep
Michael said:
> I worry that C sounds too much like
> something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
--
ralph
Re: purge: opposite of grep
Michael Lazzaro wrote: I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw designate? -- Tim
Re: purge: opposite of grep
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
>
> Some of those might be appropriate (or just amusing). :-)
I still like partition (or simply C). Segregate (c)
might also work
I notice everyone still want Int context for eval of the block:
Pease don't forget about hashes. Is there such a thing as
'hashkey context'?
Perl6 is much better than Perl5 for naming parameters. Could
we make the following work?
( low=>@under,
mid=>@in_range,
high=>@over )
= partition @input -> $v {
$v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid";
};
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
Dave.
Re: purge: opposite of grep
On Thursday, December 5, 2002, at 07:55 PM, Damian Conway wrote:
equally. The built-in would actually be doing classification of the
elements of the list, so it ought to be called C.
I worry that C sounds too much like something class-related,
and would confuse people. What about C or something? Decent
thesaurus entries for include:
assign, classify, comb, compartmentalize, discriminate, distribute,
group, order, segregate, sift, winnow, amputate, cut, dismember,
excise, lop, disunite, divorce, estrange, part, wean, detach,
disconnect, disengage, dissociate, extract, isolate, part, steal, take,
uncouple, withdraw
Some of those might be appropriate (or just amusing). :-)
The selector block/closure would, naturally, be called in C
context each time, so (again, as Larry pointed out) a boolean
function would naturally classify into two arrays. Though it
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
I was more hoping for a C or C derivative that would
provide a series of 'stream'-like tests, not just one test with N
answers. Something that was a shorthand for the obvious but somewhat
tedious C counterpart. (If @source had an entry 'foobar', we
could debate whether that should go in one destination stream or two.)
Especially since you then get your purge/vrep/antigrep for free:
I don't think we need a separate func either, but if we're gonna have a
purge/vrep/antigrep, can someone _please_ think of a better name for
it? "purge" clearly needs an inverse called "binge", "vrep" sounds
like, well, UNIX, and "antigrep" sounds like something I put in my car
to avoid it grepping when I start it on cold mornings.
Even just "ngrep" sounds better to me. :-|
MikeL
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: > For example, suppose I want to separate a list of people into people who > have never donated money and those who have. Assuming that each person > object has a donations property which is an array reference, I would want > to classify them in this manner: > > (@nevers, @donors) := classify($_->[donations]) @people; > > According to the C model, that would give me people who have donated > zero times, and people who have donated once, and the people who have > donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_->[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: > The selector block/closure would, naturally, be called in C context > each time, so (again, as Larry pointed out) a boolean function would > naturally classify into two arrays. Though it might at first be a little > counterintuitive to have to write: OK, but I would assert that the false/true classification is going to be the more common case, not "classify by index position", and that furthermore there will be a lot of situations where the false/true value may be any number, not just 1 or 0. For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_->[donations]) @people; According to the C model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Now, of course you can force the dontations into a boolean context, but, frankly, I think If we force people to always remember to force boolean context, just to preserve the (IMHO) unusual case of classifying by integer, we're, on balance, making more work for the world. Ergo, I suggest we simply have a separate command for the false/true situation: (@nevers, @donors) := falsetrue($_->[donations]) @people; (Yes, "falsetrue" is a stupid name, please replace with something better.) -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
I would suggest that we could get away with a single n-ary built-in.
And I would strongly suggest that C isn't the right name for it,
since, apart from being a ugly, slang word, "divvy" implies dividing up
equally. The built-in would actually be doing classification of the
elements of the list, so it ought to be called C.
I would expect that C would return a list of array references.
So Larry is (of course! ;-) entirely correct in pointing out that it
would require the use of := (not =). As for an error when = is used,
perhaps that ought to be handled by a general "Second and subsequent
lvalue arrays will never be assigned to" error.
The selector block/closure would, naturally, be called in C
context each time, so (again, as Larry pointed out) a boolean
function would naturally classify into two arrays. Though it
might at first be a little counterintuitive to have to write:
(@false, @true) := classify { $^x > 10 } @nums;
I think it's a small price to pay to avoid tiresome special cases.
Especially since you then get your purge/vrep/antigrep for free:
(@members) := classify {$_->{'quit'}} @members;
;-)
Damian
Re: purge: opposite of grep
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
>
> I think that c would be an abysmal name: that implies
> "keep the false ones". I'm not sure that there is a synonym
> for "boolean partition" though. Perhaps we need some help
> from a linguist! ;)
>
What's wrong with split()?
split { f($_) }, $iterator-or- @array.split { f($_) }
vs.
split /\Q$delim\E/, $string -or- $string.split( /\Q$delim\E/ )
BTW, since it's possible to say:
my (@even, @odd) = split { $_ % 2 }, 0 .. Inf;
I presume that split will be smart enough to be usefully lazy. So
laziness is probably a contagious property. (If the input is lazy, the
output probably will be, too.)
But what happens with side-effects, or with pathologically ordered
accesses?
That is, iterators tend to get wrapped with a lazy array, which caches
the accesses.
So if the discriminator function caches values of its own, what
happens?
E.g.,
# Side-effects
my (@even, @odd)
= split { is_prime($_) && $last_prime = $_; $_ % 2 }, 0..Inf;
The value of last_prime is .. ?
# Pathological access:
my (@even, @odd) = ... as above ...
print $#odd;
Does @even (which is going to be cached by the lazy array) just swamp
memory, or what?
=Austin
=Austin
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > ex(1) / vi(1) commands (where 're' stands for regular expression, of > course) : > :g/re/p > :v/re/p I like it. Fits in with our Un*x heritage, and doesn't have any existing meaning that implies things it doesn't do. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
"Miko O'Sullivan" <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Dec 2002, Dave Whipp wrote:
>
> > Only if we apply a bit of magic (2 is a true value). The rule might be:
>
> How about if we just have two different methods: one for boolean and one
> for multiple divvies:
>
> my(@true, @false) := @array.cull{/some test/};
>
> my (@a, @b, @c) := @array.divvy{some code}
I think you are correct, but only because of the psychology of
affordances: you wrote "@true, @false", not "@false, @true".
I use the same mental ordering, so I expect it would be a
common bug.
I think that c would be an abysmal name: that implies
"keep the false ones". I'm not sure that there is a synonym
for "boolean partition" though. Perhaps we need some help
from a linguist! ;)
Dave.
Re: purge: opposite of grep
John Williams wrote in perl.perl6.language : > > While "purge" is cute, it certainly is not obvious what it does. Of > course neither is "grep" unless you are an aging unix guru... > > How about something which is at least obvious to someone who knows what > grep is, such as "vgrep" or "grep:v"? If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p What would be an idiomatic Perl 6 implementation of such a vrep function ?
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Dave Whipp wrote:
> Only if we apply a bit of magic (2 is a true value). The rule might be:
How about if we just have two different methods: one for boolean and one
for multiple divvies:
my(@true, @false) := @array.cull{/some test/};
my (@a, @b, @c) := @array.divvy{some code}
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
RE: purge: opposite of grep
> FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) I like "purge", although "except", "exclude", and "omit" all have their charms. For partition function, I like "divvy", "carve", "segment" (in that order) and almost anything other than "separate", which IIRC is one of the most misspelled words in English. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson multimedia, Inc.Indianapolis IN "we have tamed lightning and used it to teach sand to think"
Re: purge: opposite of grep
"Larry Wall" <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 05, 2002 at 10:09:08AM -0800, Michael Lazzaro wrote:
> : What about "divvy" (or are we already using that for something else?)
> :
> : my(@a,@b) = divvy { ... } @c;
>
> Any such solution must use := rather than =. I'd go as far as to say
> that divvy should be illegal in a list context.
I'm not sure I understand that: we're assigning here, not binding (aren't
we?).
> Note that if the closure is expected to return a small integer saying
> which array to divvy to, then boolean operators fall out naturally
> because they produce 0 and 1.
Only if we apply a bit of magic (2 is a true value). The rule might be:
If context is an list of arrays, then the coderef is evaluated in
integer context: to map each input value to an integer, which selects
which array to append the input-value onto.
If the size of the context is "list of 2 arrays", then the coderef is
evaluated in Boolean context, and the index determined as
c< $result ?? 1 :: 0 >.
If the context is a single array, then it is assumed to be an
array-of-arrays: and the coderef is evaluated in integer-context.
If the context is a hash, then the coderef is evaluated in scalar
context, and the result used as a hash key: the value is pushed
onto the array, in the hash, identified by the key.
One more thing: how to I tell the assignment not to clear to
LHS at the start of the operation. Can I say:
my (@a,@b) = divvy { ... } @a1;
(@a,@b) push= divvy { ... } @a2;
Dave.
Re: purge: opposite of grep
On Thu, Dec 05, 2002 at 10:09:08AM -0800, Michael Lazzaro wrote:
: What about "divvy" (or are we already using that for something else?)
:
: my(@a,@b) = divvy { ... } @c;
Any such solution must use := rather than =. I'd go as far as to say
that divvy should be illegal in a list context.
Note that if the closure is expected to return a small integer saying
which array to divvy to, then boolean operators fall out naturally
because they produce 0 and 1.
Larry
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Robert Spier wrote:
> -R (who does not see any benefit of 'perg' over grep { ! code } )
My problem with grep { ! code } is the same problem I have with if (!
expression): I've never developed a real trust in operator precedence.
Even looking at your pseudocode example, I itched to "fix" it with grep {!
(code) }.
This may be a weakness on my part, but I like computers to address my
weaknesses: I certainly spend enough time addressing theirs.
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Re: purge: opposite of grep
>How about my original inclinaton: "perg"? It just screams out "the
>opposite of grep".
So it greps a list in reverse order?
-R (who does not see any benefit of 'perg' over grep { ! code } )
Re: purge: opposite of grep
On Wed, 4 Dec 2002, John Williams wrote: > While "purge" is cute, it certainly is not obvious what it does. Of > course neither is "grep" unless you are an aging unix guru... > > How about something which is at least obvious to someone who knows what > grep is, such as "vgrep" or "grep:v"? How about my original inclinaton: "perg"? It just screams out "the opposite of grep". -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
I like it except for the name, which feels too active to me (ie, if I were to
purge those elements from the array I'd expect the array to be altered, instead
of returning a new array with only those elements). But I do like the idea. I
think the name "except" would be pretty nice, though. Then again, I'm not too
terribly fond of "grep". If it were named "only", then things might be really
nice. (Or we could name them "accept" and "except" and be mean :))
> SUMMARY
>
> Proposal for the "purge" command as the opposite of "grep" in the same way
> that "unless" is the opposite of "if".
>
> DETAILS
>
> I've lately been going a lot of greps in which I want to keep all the
> elements in an array that do *not* match some rule. For example, suppose
> I have a list of members of a club, and I want to remove (i.e. "purge")
> from the list everybody for whom the "quit" property is true. With grep
> it's done like this:
>
>@members = grep {! $_->{'quit'}} @members;
>
> Obviously that works well enough, but just like "unless" somehow
> simplifies the logic by removing that leading !, "purge" can simplifiy the
> array filter:
>
>@members = purge {$_->{'quit'}} @members;
>
> FWIW, I came up with "purge" because my first inclination was to spell
> "grep" backwards: "perg". :-)
>
> -miko
>
>
> Miko O'Sullivan
> Programmer Analyst
> Rescue Mission of Roanoke
>
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I love apathy with a passion.
--Jamin Gray
Re: purge: opposite of grep
On Wednesday, December 4, 2002, at 09:11 PM, John Williams wrote:
On Wed, 4 Dec 2002, Miko O'Sullivan wrote:
FWIW, I came up with "purge" because my first inclination was to spell
"grep" backwards: "perg". :-)
While "purge" is cute, it certainly is not obvious what it does. Of
course neither is "grep" unless you are an aging unix guru...
The idea certainly has merit, though. It _is_ a quite common operation.
What about "divvy" (or are we already using that for something else?)
my(@a,@b) = divvy { ... } @c;
Other possibilities from the ol' thesaurus: C, C, C,
C.
Note that this does not generalize for cases > 2. If you want to split
things into, say, three different lists, or five, you have to use a
'given', and it gets less pleasant. Perhaps a C can be a
derivation of C or C by "dividing the streams", either like
this:
my(@a,@b,@c,@d) = divvy {
/foo/ ::
/bar/ ::
/zap/ ::
} @source;
or this (?):
divvy( @source; /foo/ :: /bar/ :: /zap/ ) -> @a, @b, @c, @d;
where C<::> is whatever delimiter we deem appropriate, and an empty
test is taken as the "otherwise" case.
Just pondering. Seems like a useful variation on the whole C
vs. C vs. C theme, though.
MikeL
Re: purge: opposite of grep
[EMAIL PROTECTED] (Miko O'Sullivan) writes: > FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) For reference, Ruby uses .detect and .reject. -- 3rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped
Re: purge: opposite of grep
On Wed, 4 Dec 2002, Miko O'Sullivan wrote: > > FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) While "purge" is cute, it certainly is not obvious what it does. Of course neither is "grep" unless you are an aging unix guru... How about something which is at least obvious to someone who knows what grep is, such as "vgrep" or "grep:v"? Or maybe that's not any better than "grep !(...)". ~ John Williams
RE: purge: opposite of grep
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
> SUMMARY
>
> Proposal for the "purge" command as the opposite of "grep" in
> the same way that "unless" is the opposite of "if".
I like it.
But reading it reminded me of another common thing I do
with grep: partitioning a list into equivalence classes.
a simple case:
@pass = grep {$_->ok} @candidates;
@fail = grep {! $_->ok} @candidates;
This could perhaps be expessed as:
(@pass, @fail) = unzip { $_->ok } @candidates;
A more general mechanism might be:
%results = partition
{ $_->pass ? "pass" : $_->fail ? "fail" : "unknown" }
@canditates;
print "pass: @{%results{pass}}";
print "fail: @{%results{fail}}";
print "unknown: @{%results{unknown}}";
Dave.
