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 <e...@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 <e...@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! _________________________ Racket Developers list: http://lists.racket-lang.org/dev
