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
>
> @
Luke Palmer wrote:
> Jonathan Lang writes:
> > How about including something similar to <==, but which binds the
> > elements of the list to the various positional parameters? For
> > instance:
> >
> > @sorted = sort {infix:<=> args map {$_.foo('bar').compute},
> > $^a, $^b
Jonathan Lang writes:
> How about including something similar to <==, but which binds the elements
> of the list to the various positional parameters? For instance:
>
> @sorted = sort {infix:<=> args map {$_.foo('bar').compute}, $^a, $^b }
> @unsorted;
>
> Where
>
> @x = $a, $
Jonathan Lang wrote:
> Luke Palmer wrote:
> > I've been thinking about this problem which comes up in my code a lot:
> >
> >@sorted = sort { $^a.foo('bar').compute <=> $^b.foo('bar').compute}
> > @unsorted;
> >
> > Often the expressions on each side are even longer than that.
Larry Wall wrote:
> What I'm currently thinking about is a "does" predicate that tells you
> if an object/class does a particular role completely. If you pull
> part of a role into a class, it returns false, because it doesn't do
> the complete role. However, if you use "like" instead, it returns
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
Larry Wall wrote:
I only see like() as counting the methods available through the public
contract to determine its percentage. Something you could do by hand with
.can(). But there wouldn't be much point in putting it in if people
won't use it. On the other hand, if people want it and it's not t
On Thu, Feb 12, 2004 at 12:02:50PM -0800, chromatic wrote:
: Is it more useful to find the Dog-like-ness of a class or the notion
: that SomeClass.bark() is semantically Dog-like, not Tree-like?
I expect we'd use .can() for method-based queries.
: I expect to care more that the object does someth
On Thu, 2004-02-12 at 11:49, Larry Wall wrote:
> What I'm currently thinking about is a "does" predicate that tells you
> if an object/class does a particular role completely. If you pull
> part of a role into a class, it returns false, because it doesn't do
> the complete role. However, if you
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, Feb 12, 2004 at 11:03:57AM -0800, chromatic wrote:
: On a conceptual level, the different syntax is the worst crime because
: it reinforces the idea that the important question about an object is
: "What is this object's position in a class hierarchy?", not "Does this
: object have the same
On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote:
> Perhaps I'm slow, but I don't see the difference between a trait and a
> Java interface other than the fact that traits appear to be more of a
> run-time construct.
The easy answer is that interfaces completely suck while traits don't.
:)
Seri
Yes, that's a very good paper, which is why Perl 6 now has something
called Roles, which are intended to degenerate either to Traits or
Interfaces. My take on it is that Roles' most important, er, role
will be to abstract out the decision to compose or delegate. But we'd
like them to function as
At 11:40 PM -0500 2/11/04, Joe Gottman wrote:
This is unrelated to the problem you mentioned, but there is another
annoying problem with sort as it is currently defined. If you have an
@array and you want to replace it with the sorted version, you have to type
@array = sort @array;
That wou
Aaron Sherman wrote:
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interface other than the fact that traits appear to be more of a
run-time construct.
Java interfaces are actually a very nice compromise between multiple and
single inheritance.
You can not get rid of t
On Thu, 2004-02-12 at 08:14, Dmitry Dorofeev wrote:
> I see that i am not alone in my thoughts about classic OO drawbacks.
> Some smart people created traits for SmallTalk which is something
> close to what i want.
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interf
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(&@) {
Hi all,
I see that i am not alone in my thoughts about classic OO drawbacks.
Some smart people created traits for SmallTalk which is something
close to what i want.
Traits are mechanism, recently proposed by Scharli et al, for factoring Smalltalk class hierarchies. By separating the issue of code
> ...
> 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
On Thu, 12 Feb 2004 15.40, Joe Gottman wrote:
>This is unrelated to the problem you mentioned, but there is another
> annoying problem with sort as it is currently defined. If you have an
> @array and you want to replace it with the sorted version, you have to type
> @array = sort @array;
Joe Gottman wrote in perl.perl6.language :
>This is unrelated to the problem you mentioned, but there is another
> annoying problem with sort as it is currently defined. If you have an
> @array and you want to replace it with the sorted version, you have to type
> @array = sort @array;
>
35 matches
Mail list logo
