>>>>> "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) returns Int;
DC> @sorted = sort &fuzzy_cmp, @unsorted;
>>
>> ok, so that is recognizes as a compare sub due to the 2 arg sig. so does
>> the sub must be defined/declared before the sort code is compiled?
LP> Nope. C<sort> is declared as a multimethod. This works, too:
LP> $code = sub ($a, $b) { -M $a <=> -M $b };
LP> @sorted = sort $code, @unsorted;
that didn't answer my question. your code is still seen before the sort
call. IMO, the signature is needed to be seen beforehand so sort can
decide if the code (in whatever form) is a 1 arg extractor or a 2 arg
comparator.
DC> # Key-ifically...
DC> sub get_key($elem) {...}
DC> @sorted = sort &get_key, @unsorted;
>>
>> and that is parsed as an extracter code call due to the single arg
>> sig. again, it appears that it has to be seen before the sort code for
>> that to work.
LP> Nope. Runtime dispatch as before.
oh, i get it now. braino on my part. it is multimethod dispatch at run
time using the parse tree from damian's post.
>>
DC> # Modtimewise stringifically descending...
DC> @sorted = sort {-M}=>{$^b cmp $^a} @unsorted;
>>
>> so that is a single pair of extractor/comparator. but there is no comma
>> before @unsorted. is that correct? see below for why i ask that.
LP> Yes. Commas may be ommitted on either side of a block when used as an
LP> argument. I would argue that they only be omitted on the right side, so
DC> ],
>>
>> but what about that comma? no other example seems to have one before the
>> @unsorted stuff.
LP> It's not a closure, so you need a comma.
ok, that is more p6 syntax that will need to be relearned often. be nice
when we have a real lang to play with and learn from. :)
DC> @unsorted;
>>
DC> If a key-extractor block returns number, then C<< <=> >> is used to
DC> compare those keys. Otherwise C<cmp> is used. In either case, the keys
DC> extracted by the block are cached within the call to C<sort>, to
DC> optimize subsequent comparisons against the same element. That is, a
DC> key-extractor block is only ever called once for each element being
DC> sorted.
>>
>> where does the int optimizer come in? just as you had it before in the
>> extractor code? that will need to be accessible to the optimizer if the
>> GRT is to work correctly.
LP> If the block provably returns an int, C<sort> might be able to optimize
LP> for ints. Several ways to provably return an int:
LP> my $extractor = an int sub($arg) { $arg.num }
LP> @sorted = sort $extractor, @unsorted;
LP> Or with a smarter compiler:
LP> @sorted = sort { int .num } @unsorted;
LP> Or C<sort> might even check whether all the return values are ints and
LP> then optimize that way. No guarantees: it's not a language-level issue.
oh, i understand that optimization is always optional and implementation
specific. but i just wanted to make sure the proper hints can be
provided to the sort optimizer. i didn't notice any int examples in
damian's opus whereas he covered them earlier in the thread.
>> i like that the key caching is defined here.
LP> Yeah. This is a language-level issue, as the blocks might have
LP> side-effects.
good point there. i usually think of them as an optimization issue. so
we should document that reason for them as well as being faster.
>> this is very good overall (notwithstanding my few nits and
>> questions). it will satisfy all sorts of sort users, even those who
>> are out of sorts.
LP> Agreed. I'm very fond of it..
good to hear. now let's dump some new fun problem on damian's strong
back and larry's nimble fingers. :)
and i should try to resurrect my Sort::GRT module as i have been
thinking about it. it will be a good thing to work from for the p6
implementation.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
