On Friday, February 20, 2004, at 05:48 , Damian Conway wrote:
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do
you look at the signature, or do you simply evaluate the result of
the key-extractor for each element in the unsorted list? For example,
wha
Smylers wrote:
Oh. I'd been assuming that quote marks indicated strings, and that,
while a string containing only digits could obviously be treated as a
number (as in Perl 5), it wouldn't be one without being provoked.
Correct.
What about:
$x = '0345';
Is that a number?
Nope. A string (un
Luke wrote:
I think you're forgetting what language you're talking about. Those are
numbers. After this statement:
$x = '345';
C<$x> is a number.
I don't think so. C<$x> is, of course, a variable. And what it contains after
that statement will depend on whether the variable is explicitly
Smylers wrote:
sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings
Nope.
> and that the C<< => >>
Uri wondered:
DC> No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
so how is that allowed there without a block?
A Code object in a scalar context yields a Code reference.
Damian
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do you
look at the signature, or do you simply evaluate the result of the
key-extractor for each element in the unsorted list? For example, what is
the result of the following code?
sort {$_.key} (1=> 'a
Smylers writes:
> Luke Palmer writes:
>
> > After this statement:
> >
> > $x = '345';
> >
> > C<$x> is a number.
>
> Oh. I'd been assuming that quote marks indicated strings, and that,
> while a string containing only digits could obviously be treated as a
> number (as in Perl 5), it would
At 2:49 PM -0700 2/20/04, Luke Palmer wrote:
After this statement:
$x = '345';
C<$x> is a number.
No, it isn't. It's a string. Or, rather, it's a PerlScalar.
I should hope it would be treated as one during
multimethod dispatch.
I should certainly hope *not*. If so, it's a bug. We ought to go
Luke Palmer writes:
> After this statement:
>
> $x = '345';
>
> C<$x> is a number.
Oh. I'd been assuming that quote marks indicated strings, and that,
while a string containing only digits could obviously be treated as a
number (as in Perl 5), it wouldn't be one without being provoked.
>
Smylers writes:
> Joe Gottman writes:
>
> > sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
> >
> > There is nothing in the signature of the key-extractor to suggest that
> > all the keys are numbers, but as it turns out they all are.
>
> Are they? I'd been presuming that pair keys would alw
Joe Gottman writes:
> sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
>
> There is nothing in the signature of the key-extractor to suggest that
> all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings (as
for hashes in
Smylers writes:
> Luke Palmer writes:
>
> > Uri Guttman writes:
> >
> > > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
> >
> > > DC> @sorted = sort {-M}=>{$^b cmp $^a} @unsorted;
> > >
> > > but there is no comma before @unsorted. is that correct?
> >
> > Yes. Commas may be
Luke Palmer writes:
> Uri Guttman writes:
>
> > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> > DC> @sorted = sort {-M}=>{$^b cmp $^a} @unsorted;
> >
> > but there is no comma before @unsorted. is that correct?
>
> Yes. Commas may be ommitted on either side of a block whe
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri bemoaned:
cause you agonize me head!
DC> sort &infix:<=> @unsorted
>> my brane hertz!!
>> so that declares (creates?) an infix op as a code block?
DC> No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
On Fri, Feb 20, 2004 at 02:47:55PM +1100, Damian Conway wrote:
: Yep. Inside the body of C you'd access them as:
:
: $by.trait{descending}
: $by.trait{insensitive}
:
: (unless Larry's changed the trait accessor syntax since last I looked).
Well, if traits are just compile-time proper
Uri bemoaned:
DC> sort &infix:<=> @unsorted
my brane hertz!!
so that declares (creates?) an infix op as a code block?
No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
amazing how you and luke both came up with the exact same answer.
"Great minds..." etc. ;-)
> p6 synt
> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes:
JG>How do you decide whether a key-extractor block returns number? Do you
JG> look at the signature, or do you simply evaluate the result of the
JG> key-extractor for each element in the unsorted list? For example, what is
JG> t
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Uri Guttman writes:
>> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> # Modtimewise numerically ascending...
DC> @sorted = sort {-M $^a <=> -M $^b} @unsorted;
>>
DC> # Fuzz-ifically...
DC> sub fuzzy_cmp($x, $y) r
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> No. But this will work:
DC> sort &infix:<=> @unsorted
my brane hertz!!
so that declares (creates?) an infix op as a code block? and since <=>
is known to take 2 args it is parsed (or multidispatched) as a
comparator block for sor
Uri checked:
DC> @sorted = sort {$^a <=> $^b} @unsorted;
so because that has 2 placeholders, it is will match this signature:
type Comparator ::= Code(Any, Any) returns Int;
Correct.
i have to remember that placeholders are really implied args to a code
block and not just in the
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Thursday, February 19, 2004 8:29 PM
Subject: [perl] The Sort Problem: a definitive ruling
> C in Perl6 is a global multisub:
>
> multi sub *sort(Criterion @by: [EMAIL PROT
Luke Palmer writes:
> Yes. Commas may be ommitted on either side of a block when used as an
> argument. I would argue that they only be omitted on the right side, so
> that this is unambiguous:
>
> if some_function { ... }
> { ... }
>
> Which might be parsed as either:
>
> if (so
Uri Guttman writes:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
> DC> # Modtimewise numerically ascending...
> DC> @sorted = sort {-M $^a <=> -M $^b} @unsorted;
>
> DC> # Fuzz-ifically...
> DC> sub fuzzy_cmp($x, $y) returns Int;
> DC> @sorted = sort
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> # Stringifically ascending...
DC> @sorted = sort @unsorted;
DC> or with a single two-argument block/closure (to sort by whatever the
DC> specified comparator is):
DC> # Numerically ascending...
DC> @sorte
Dave Whipp wondered:
@sorted = sort {-M} @unsorted;
One thing I've been trying to figure out reading this: what is the signature
of prefix:-M ? i.e. how does it tell the outer block that it (the
outer-block) needs a parameter?
It doesn't. As A6 explained:
http://dev.perl.org/perl6/apocalypse
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> "Once again the Iron Designer rises to the supreme challenge of
DC> the Mailinglist Stadium and expresses the true spirit of Perl
DC> 6!!!"
and the challenge for next week is slicing squid with noodles!
(or cutting down the mightie
Dave Whipp writes:
> "Damian Conway" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > type KeyExtractor ::= Code(Any) returns Any;
>
> > # Modtimewise numerically ascending...
> > @sorted = sort {-M} @unsorted;
>
>
> One thing I've been trying to figure out readin
"Damian Conway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> type KeyExtractor ::= Code(Any) returns Any;
> # Modtimewise numerically ascending...
> @sorted = sort {-M} @unsorted;
One thing I've been trying to figure out reading this: what is the signature
of pref
On Mon, Feb 16, 2004 at 01:04:01AM -0700, Luke Palmer wrote:
: This is pattern matching more than it is type comparison. And Perl's
: all about pattern matching. I'm just wondering whether it needs I
: pattern archetectures.
I suspect it does, at least from the viewpoint of mere mortals. The
reg
Damian Conway wrote:
Uri persisted:
> but int is needed otherwise? int is more commonly a sort key than
float.
> it just feels asymetrical with one having a symbol and the other a
named
> operator.
Sorry, but that's the way the language works. The more general and usual
conversion (to number, n
Uri Guttman writes:
> > "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
>
> LP> Uri Guttman writes:
> >> because that would be the default comparison and the extracted key value
> >> would be stringified unless some other marker is used. most sorts are on
> >> strings so this would be
Damian Conway writes:
> type KeyExtractor ::= Code(Any) returns Any;
>
> type Comparator ::= Code(Any, Any) returns Int;
>
> type Criterion::= KeyExtractor
> | Comparator Pair(KeyExtractor, Comparator)
> ;
>
> type Criteria
Uri persisted:
> DC> How do you know that the values of %lookup are strings? DC> How
> would the optimizer know?
>
> because that would be the default comparison and the extracted key value
> would be stringified unless some other marker is used. most sorts are on
> strings so this would be a
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Uri Guttman writes:
>> because that would be the default comparison and the extracted key value
>> would be stringified unless some other marker is used. most sorts are on
>> strings so this would be a useful huffman and removal of
Uri Guttman writes:
> because that would be the default comparison and the extracted key value
> would be stringified unless some other marker is used. most sorts are on
> strings so this would be a useful huffman and removal of a redundancy.
While I like where most of this is going, I beg to diff
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri wrote:
DC> @out = sort
DC> [ { ~ %lookup{ .{remotekey} } }, #1
>> if string cmp is the default, wouldn't that ~ be redundant?
DC> How do you know that the values of %lookup are strings?
DC
Uri wrote:
DC> If a key-extractor block returns number, then C<< <=> >> is used to
DC> compare those keys. Otherwise C is used. In either case, the
DC> returned keys are cached to optimize subsequent comparisons against
DC> the same element.
i would make cmp the default as it is now.
Err
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Suppose C's signature is:
DC> type KeyExtractor ::= Code(Any) returns Any;
DC> type Comparator ::= Code(Any, Any) returns Int;
DC> type Criterion::= KeyExtractor
DC> | Comparator
Joe Gottman asked:
If we use this signature, won't the code
sort ('foo', 'bar', 'glarch');
attempt to use the first parameter as a Criteria?
No. Because a string like 'foo' wouldn't match the first parameter's type.
Since sort has to be a multi sub anyhow, why don't we do
multi s
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Larry Wall" <[EMAIL PROTECTED]>
Cc: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Sunday, February 15, 2004 5:59 PM
Subject: [perl] Re: The Sort Problem
> Here&#x
Here's a proposed syntax and semantics for C that tries to preserve the
(excellent) features of Uri's "on the right track" proposal whilst integrating
it into the Perl 6 design without multiplying entities (especially colons!)
unnecessarily.
Suppose C's signature is:
type KeyExtractor ::=
Austin Hastings wrote:
Off the top of my head, I can't think of a case where the compare sub
would be needed unless the key was not well-ordered. Does anyone have
an example of a case where the key-extraction sub approach doesn't
reduce the problem to a Scalar comparison?
I can't find the P5 c
> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> --- Uri Guttman <[EMAIL PROTECTED]> wrote:
>> there are rare times when you need a computed comparison, say with
>> a specialized collation sequence. if this sequence isn't supported
>> by locale or whatever, you need to do a c
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
>
> AH> --- Uri Guttman <[EMAIL PROTECTED]> wrote:
> >> @out = sort
> >> key:compare( \&my_compare_sub ) ( /(\d+)$/ ),
> >> @in ;
>
> >> note that the custome compare callbacks can be
> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> --- Uri Guttman <[EMAIL PROTECTED]> wrote:
>> @out = sort
>> key:compare( \&my_compare_sub ) ( /(\d+)$/ ),
>> @in ;
>> note that the custome compare callbacks can be a block or a sub
>> name/ref. the callback sub would be p
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> @out = sort
> key( %lookup{ .{remotekey} } ),
> key:insensitive:descending:locale( 'somewhere' )( .{priority} ),
> key:float ( substr( 0, 10 ) ),
> key:integer ( /foo(\d+)bar/ ),
>
On Thu, 2004-02-12 at 18:50, Uri Guttman wrote:
> there are only a short list of key comparisons possible, int, string,
> float and maybe unicode. i separate int from float since they do have
> different internals in the GRT. it is one area where you do expose
> stuff. otherwise you could just use
Friday 13 February 2004 15:02, Dan Sugalski wrote:
>
> If you're *really* looking to get fancy, why not just allow the
> sort specification to be done with SQL? Comfortable,
> well-understood, already has a decade or so of stupid things welded
> into it [...]
>
> Heck, you could even unify map, gr
At 11:52 PM -0700 2/12/04, Luke Palmer wrote:
But it needs some major syntax work so it can feel more like it's a part
of the language instead of a library function. Not, mind, that I think
Perl's syntax needs to be changed at all to accommodate.
Since everyone's well past mad here and deep into d
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> Here's my stab at a sort syntax, pulling syntax over from REs:
RA> @out
RA> <== sort key:ri($_->[2]), key:s($_->[4])
RA> <== @in;
RA> Basicly, you have a list of RE syntax like C values, whilch take
RA> various modifiers to
Am Freitag, 13. Februar 2004 01:40 schrieb Larry Wall:
> On Thu, Feb 12, 2004 at 04:29:58PM -0500, Uri Guttman wrote:
> : again, confusing. why should the order of a binary operator mean so
> : much? the order of a sort key is either ascending or descending. that is
> : what coders want to specify.
Here's my stab at a sort syntax, pulling syntax over from REs:
@out
<== sort key:ri($_->[2]), key:s($_->[4])
<== @in;
Basicly, you have a list of RE syntax like C values, whilch take
various modifiers to say how to play with that key, and then an expr on
how to generate the key given element $
Jonathan Lang writes:
> > We already have that. It's spelled:
> >
> > routine [EMAIL PROTECTED];
> >
> > Or
> >
> > routine * <== @x;
>
> Then you've got your solution:
>
> @sorted = sort {infix:<=> * map {$_.foo('bar').compute}, $^a, $^b }
> @unsorted;
>
> or
>
> @
On Thu, Feb 12, 2004 at 04:29:58PM -0500, Uri Guttman wrote:
: again, confusing. why should the order of a binary operator mean so
: much? the order of a sort key is either ascending or descending. that is
: what coders want to specify. translating that to the correct operator
: (cmp or <=>) and th
On Thu, Feb 12, 2004 at 09:37:37PM +, Simon Cozens wrote:
: [EMAIL PROTECTED] (Aaron Crane) writes:
: > That is, rinfix: (or some other name) is like infix:, but gives you a
: > function that reverses its arguments before actually running the operator.
: > Perhaps it could even be implemented a
> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes:
AS> On Thu, 2004-02-12 at 15:46, Uri Guttman wrote:
>>
>> how do you select descending order? and how do you selecte that per
>> key?
>> you can't provide a binary operator without also providing the
>> order. and what about di
On Thu, 2004-02-12 at 15:46, Uri Guttman wrote:
> > "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
> LP> Ok, I have to say, that's pretty good. Er, really good. I like it a
> LP> lot.
>
> how do you select descending order? and how do you selecte that per key?
> you can't provide a bin
[EMAIL PROTECTED] (Dave Whipp) writes:
> @sorted = sort { infix:<=> map { scalar $_.foo('bar').compute } @^_ } }
> @data
Abusing the rubyometer slightly:
@data = @sorted.sort( op => &infix:<=>, key => { $^a.foo('bar').compute } );
--
If the code and the comments disagree, then both are probably
Perhaps something like:
@sorted = sort { infix:<=> map { scalar $_.foo('bar').compute } @^_ } }
@data
I'm not entirely sure it's readability is better than yours, though.
Dave.
"Luke Palmer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I've been thinking about this problem whi
[EMAIL PROTECTED] (Aaron Crane) writes:
> One option might be an 'rsort' function, but I think that's somewhat lacking
> in the taste department.
Agreed.
> Another might be as simple as
>
> @unsorted ==> sort ==> reverse ==> @sorted;
@sorted <== sort <== @unsorted, no? ;)
> @unsorted ==>
Aaron Crane writes:
> I have one other idea, but I can't decide if I like it:
>
> @unsorted ==> sort &rinfix:cmp ==> @sorted;
>
> That is, rinfix: (or some other name) is like infix:, but gives you a
> function that reverses its arguments before actually running the operator.
> Perhaps it could
> "AC" == Aaron Crane <[EMAIL PROTECTED]> writes:
AC> One option might be an 'rsort' function, but I think that's
AC> somewhat lacking in the taste department.
AC> Another might be as simple as
AC> @unsorted ==> sort ==> reverse ==> @sorted;
again, reverse order needs to be on a p
Luke Palmer wrote:
> Aaron Crane writes:
> > @unsorted
> > ==> sort &infix:<=>, desc => 1, key => { $_.foo('bar').compute }
> > ==> @sorted;
>
> I don't like the C flag. But I can't, at the moment, think of any
> way around it short of:
>
> @unsorted
> ==> sort { $^b <=> $^
> "PM" == Ph Marek <[EMAIL PROTECTED]> writes:
>> ...
>> so here is a (very rough and probably broken) syntax idea building on
>> that:
>>
>> sort :key { :descend :string .foo('bar').substr( 10, 3) }
>>
>> :key { :int .foo('baz') }
>> :key { :float .foo('amo
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
>> # P5: @sorted = sort { $a->foo('bar')->compute <=> $b->foo('bar')->compute }
>> # @unsorted
>> # or: @sorted = map { $_->[1] }
>> # sort { $a->[0] <=? $b->[0] }
>> # map { [ $_->foo('bar')-
Aaron Crane writes:
> Luke Palmer wrote:
> > Any other ideas?
>
> How about something like this, modulo any errors in my Perl 6 syntax?
>
> sub sort(?&cmp = &infix:cmp, +$key, +$desc, [EMAIL PROTECTED]) { ... }
>
> I think that allows all of these:
>
> # P5: @sorted = sort @unsorted;
> @s
On Thu, Feb 12, 2004 at 12:07:37PM +0100, Ph. Marek wrote:
: > ...
: > so here is a (very rough and probably broken) syntax idea building on
: > that:
: >
: > sort :key { :descend :string .foo('bar').substr( 10, 3) }
: >
: > :key { :int .foo('baz') }
: > :key { :float .f
On Thu, 2004-02-12 at 08:43, Aaron Sherman wrote:
> sub sortpairs(&@) {
> my $comp = shift;
> my %pairs = @_;
> return map {$pairs{$_}} sort {$comp->($a)} keys %pairs;
> }
Doh... it's early for me. That's C()}> with no parameter.
The fact that $a and $b are dynamically scoped in Perl 5 help
On Thu, 2004-02-12 at 01:59, Uri Guttman wrote:
> sorry about the confusion. read the paper at:
>
> http://www.sysarch.com/perl/sort_paper.html
All of which stops being a concern if you have a sort variant that works
on pairs in the first place. Perl _5_ code follows:
sub sortpairs(&@) {
> ...
> so here is a (very rough and probably broken) syntax idea building on
> that:
>
> sort :key { :descend :string .foo('bar').substr( 10, 3) }
>
> :key { :int .foo('baz') }
> :key { :float .foo('amount') } @unsorted ;
I see a kind of problem here: If the parts of th
Luke Palmer wrote:
> Any other ideas?
How about something like this, modulo any errors in my Perl 6 syntax?
sub sort(?&cmp = &infix:cmp, +$key, +$desc, [EMAIL PROTECTED]) { ... }
I think that allows all of these:
# P5: @sorted = sort @unsorted;
@sorted = sort @unsorted;
The simplest case
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> Uri Guttman writes:
>> > "GNP" == Gregor N Purdy <[EMAIL PROTECTED]> writes:
>>
GNP> (But, the GRT doesn't apply to sorting general objects, and the
GNP> example has @unsorted containing objects on which we run
GNP> .foo('b
Uri Guttman writes:
> > "GNP" == Gregor N Purdy <[EMAIL PROTECTED]> writes:
>
> GNP> (But, the GRT doesn't apply to sorting general objects, and the
> GNP> example has @unsorted containing objects on which we run
> GNP> .foo('bar').compute.)
>
> there are no restrictions on what the GRT
> "GNP" == Gregor N Purdy <[EMAIL PROTECTED]> writes:
GNP> The Schwartzian is the usual way, of course:
GNP> map { $_->[1] }
GNP> sort { $^a[0] <=> $^b[0] }
GNP> map { [ $_.foo('bar').compute, $_ ] }
GNP> @unsorted;
and the GRT is another.
let stick my nose in here. sorti
Luke --
Hmmm... I haven't been practicing my Perl 6, and its been a while
since the last Apocalyptic refresher, but here goes (I'll don a paper
bag preemptively)...
Thinking of that as the equivalent to:
sort {
my ($ta, $tb) = map { $_.foo('bar').compute } ($^a, $^b);
$ta <=> $tb
} @
75 matches
Mail list logo
