[racket-dev] [racket] Feature request: multiple keys in sort

How about this: until you find the perfect way to do this, we just add
two new optional keyword arguments to sort that deal with two levels
of key/sorts? eg:

(sort lst < #:key first #:key2 second)

would mean to sort by < for both keys, treating the first position in
the list as the main one and the second as a secondary one. And then
we could also have another keyword for specifying a different sorting
predicate for the second key, too.

That would actually cover all of the cases that I think I've seen in practice.

Robby

On Mon, Jun 11, 2012 at 1:58 PM, Eli Barzilay <eli at barzilay.org> wrote:
> [Setting followups to the dev list.]
>
> 20 minutes ago, Robby Findler wrote:
>> On Mon, Jun 11, 2012 at 11:37 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> > So the bottom line is that there's no need to extend `sort' for
>> > this kind of functionality.  What would be nice to have though, is
>> > such a comparison combinator -- and the only reason there's
>> > nothing that comes pre-packaged is that I didn't see something
>> > that sticks out as the right api for it.  (See srfi-67 for a very
>> > complete discussion, and a post that I'll send to the dev list
>> > soon.)
>>
>> I'm not sure I buy this conclusion here: the reason to put it into
>> sort (or somewhere) would be a) convenience and b) maintainability
>> (since this comes up fairly often at least in my own experience and
>> having something short to read to know what is going on is
>> preferable to having to read a bunch of code to figure out what is
>> going on). No?
>
> What I meant is that there is no need to extend `sort' itself -- but
> there is definitely a place for having such a comparison combinator.
> The only question is what kind of combinator... and because I didn't
> (and still don't) have a good answer for that question, I didn't
> implement it.  To make it even clearer -- if, for some reason, the
> code that I wrote in the previous post is universally accepted as the
> perfect tool, then there's no doubt that it should be added.  (But I
> think that it suffers from a bunch of problems.)
>
>
> And another appendix that I should have added: things get more
> complicated in the presence of `#:cache-keys?'.  If there's just this
> kind of a combinator, and you need to precompute a number of keys,
> then you end up with some amount of boilerplate -- something like:
>
>  (sort some-list
>        (<... smaller1? car smaller2? cadr ...)
>        #:key (λ (x) (list (compute-key1 x) (compute-key1 x) ...))
>        #:cache-keys? #t)
>
> This means that the combinator is not as useful, since you need to
> split the code: instead of specifying `smaller1?' and `compute-key1'
> together, you need to split them to two places, and you need to decide
> on the intermediate representation for the tuples.  A solution for
> this particular case does require an extension to `sort'.  However, it
> seems to me like a relatively rare case, and the benefits of such an
> extension should be weighed against the more complicated interface
> that `sort' will have, and the fact that with baking this into `sort'
> we're losing the ability to conveniently add additional kinds of
> combinators.
>
> (This is also related to the other post that I'll do.)
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!