[racket] Feature request: multiple keys in sort

[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!