Front page | perl.perl6.language |
Postings from February 2004
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 expression
Indeed.
> 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?
Yes. And, yes, declaration is sufficient.
> DC> @sorted = sort {+ $^elem} @unsorted;
> DC> @sorted = sort {+ $_} @unsorted;
>
> is $^elem special? or just a regular place holder?
Regular.
> just getting my p6 chops back. .name is really $_.name so that makes
> sense. and $^elem is just a named placeholder for $_ as before?
Yes and yes.
> DC> @sorted = sort &get_key, @unsorted;
>
> and that is parsed as an extracter code call due to the single arg
> sig.
Yes.
> again, it appears that it has to be seen before the sort code for
> that to work.
Correct.
> DC> or with a single extractor/comparator pair (to sort according to the
> DC> extracted key, using the specified comparator):
>
> 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.
Typo. I'm pretty sure it would actually need a comma there.
> DC> @sorted = sort {.name}=>&fuzzy_cmp @unsorted;
Comma required there too. :-(
> DC> ],
>
> but what about that comma?
It's required.
> no other example seems to have one before the @unsorted stuff.
The comma exception only applies to simple blocks. I messed up those two
examples. :-(
> where does the int optimizer come in?
When the key extractor is known to return an Int. Which would occur either
when it's explicitly declared to do that, or when the compiler can intuit a
block's return type from the type of value returned by the block (i.e. if the
block always returns the result of a call to C<int>).
> just as you had it before in the
> extractor code?
Yup.
> so are those traits are only allowed/meaningful on comparison blocks?
> or will an extraction block take them
Both. That's why I wrote:
The C<is descending> and C<is insensitive> traits
on a key extractor or a comparator..."
^^^^^^^^^^^^^
> you have examples which show the
> traits on either the extractor or comparator code blocks. that implies
> that the guts can get those flags from either and use them as needed.
Yep. Inside the body of C<sort> you'd access them as:
$by.trait{descending}
$by.trait{insensitive}
(unless Larry's changed the trait accessor syntax since last I looked).
Damian
Thread Previous
|
Thread Next