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
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
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
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
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
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
[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
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
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
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?
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
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
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
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?
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
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
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
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
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);
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;
[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
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,
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
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,
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 {
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
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,
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
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
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,
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:
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
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
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.
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?
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
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
[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
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
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
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
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 } )
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
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
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
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
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
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
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
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
--- 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
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
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
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.
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
55 matches
Mail list logo
