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
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 {
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 you
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;
>
>
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
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 w
> 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 t
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 variab
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 understan
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)
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
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
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
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:
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
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? et
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 c
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,
[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
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 i
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,
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 {
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,
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 method
> 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...
>
>
[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
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;
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
> 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
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 class
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,@
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
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 t
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 reg
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
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?
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 buil
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:/
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) :
> >
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 r
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:
... -> .
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, c
"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
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 someth
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 clas
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,
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
--- 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($_) }, $ite
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 existin
"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.c
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"?
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 co
> 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 "sepa
"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
>
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.
Not
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 itche
>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 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 a
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 a
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 neit
[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 dum
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 somet
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
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 membe
64 matches
Mail list logo
