RE: purge: opposite of grep
It just occurred to me that Cpart is almost a specialization of
Csort. 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 Csort 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: '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
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 Cpart 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
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 Cpush, Cpop,
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 Cfor 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: '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 Cwant 'hashkey' is a useful think to know. Damian
Re: purge: opposite of grep
Brent Dax wrote:
It just occurred to me that Cpart is almost a specialization of
Csort. 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: purge: opposite of grep
[EMAIL PROTECTED] (Damian Conway) writes: Of course, as long as you can call Cpart without explicitly loading a module, it's merely a philosophical distinction as to whether Cpart 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
On Sun, Dec 08, 2002 at 11:28:24AM +1100, Damian Conway wrote: We could certainly do that. But let's call it Cpart. I usually just lurk here, but I just had to pipe in. :) I'm not sure the meaning of the name Cpart would be obvious to someone who hadn't seen it before. I keep thinking Csift would be nice, or maybe Cdiscrim. Just a thought... - Ian.
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 Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: I keep thinking Csift would be nice, or maybe Cdiscrim. Just a thought... Csift is quite good. Though I still like Cpart best. Ooh, I like Csift best. Cpart 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
David Wheeler wrote: On Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: Ian Remmler decloaked and wrote: I keep thinking Csift would be nice ... Csift is quite good. Though I still like Cpart best. Ooh, I like Csift best. I dislike Csift cos it's a small typo away from Cshift. Smylers
Re: purge: opposite of grep
On Sunday, December 8, 2002, at 10:20 AM, Smylers wrote: I dislike Csift cos it's a small typo away from Cshift. 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
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 CArray::kv 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 Cany(1).
Then, within Cpart, 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 Cany(0,1).
Then, within Cpart, 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 CArray::operator:[] 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 Cparting 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 CList::Utils::reduce or CList::Utils::max.
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 $_;
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
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
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
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
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
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 Cpart.
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:
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
[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
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
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 Cpart without explicitly loading a module, it's merely a philosophical distinction as to whether Cpart is core or not. Damian
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 Cmap, Cgrep, Creduce 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
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 Cmap. 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 Cgrep, after all. It should be easy.
Was it ever decided what Cfor would look like with multiple streams?
Maybe we could just use the stream delimiters in the Cgrep like we do
in Cfor?
grep {
/foo/ - @foo,
/bar/ - @bar,
/zap/ - @zap,
} @source;
???
MikeL
Re: purge: opposite of grep
Ian Remmler decloaked and wrote: I'm not sure the meaning of the name Cpart would be obvious to someone who hadn't seen it before. What, as opposed to Cgrep or Cmap or Csplice or Cqr or Cflock or Cref or Cfork or Cchomp or Ccrypt or Cgetservent or Cucfirst or Clstat or Cvec or...? ;-) I keep thinking Csift would be nice, or maybe Cdiscrim. Just a thought... Csift is quite good. Though I still like Cpart best. Damian
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: The selector block/closure would, naturally, be called in Cint 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 Cint 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
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 Cint 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 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 Cclassify.
I worry that Cclassify sounds too much like something class-related,
and would confuse people. What about Carrange or something? Decent
thesaurus entries for separate 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 Cint
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 Cfor or Cgiven 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 Cgiven 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
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 said:
I worry that Cclassify 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
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
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
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
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
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
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
[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 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: Callot, Cdeal, Cdole,
Cdispense.
thinking aloud...
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 Cdivvy can be a
derivation of Cgiven or Cfor 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 Cgiven
vs. Cgrep vs. Cfor theme, though.
MikeL
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 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
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 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
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
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
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
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
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
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 ccull 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
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
--- Dave Whipp [EMAIL PROTECTED] wrote:
I think that ccull 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
I would suggest that we could get away with a single n-ary built-in.
And I would strongly suggest that Cdivvy 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 Cclassify.
I would expect that Cclassify 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 Cint
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
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.
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
