<html><head></head><body>Hi Jordan, The simplest change I see to your code... (define-values (year month day) (regexp-split #rx"/" "2012/06/06")) ...is this: (define-values (year month day) (apply values (regexp-split #rx"/" "2012/06/06"))) Best, jmj -- Sent from my Android phone with K-9 Mail. <div class="gmail_quote">users-request@racket-lang.org wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre style="white-space: pre-wrap; word-wrap:break-word; font-family: monospace">Send users mailing list submissions to users@racket-lang.org To subscribe or unsubscribe via the World Wide Web, visit <a href="http://lists.racket-lang.org/users/listinfo">http://lists.racket-lang.org/users/listinfo</a> or, via email, send a message with subject or body 'help' to users-request@racket-lang.org You can reach the person managing the list at users-owner@racket-lang.org When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..." [Racket Users list: <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a>] Today's Topics: 1. Re: Feature request: multiple keys in sort (Eli Barzilay) 2. Re: Feature request: multiple keys in sort (Robby Findler) 3. unwrapping a list (Jordan Schatz) 4. Re: unwrapping a list (Erik Silkensen) 5. Re: unwrapping a list (Eli Barzilay) 6. Re: unwrapping a list (Neil Van Dyke) <hr /> Message: 1 Date: Mon, 11 Jun 2012 14:58:47 -0400 From: Eli Barzilay <eli@barzilay.org> To: Robby Findler <robby@eecs.northwestern.edu> Cc: Harry Spier <vasishtha.spier@gmail.com>, racket List <users@racket-lang.org> Subject: Re: [racket] Feature request: multiple keys in sort Message-ID: <20438.16359.371830.465004@winooski.ccs.neu.edu> Content-Type: text/plain; charset=utf-8 [Setting followups to the dev list.] 20 minutes ago, Robby Findler wrote: > On Mon, Jun 11, 2012 at 11:37 AM, Eli Barzilay <eli@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: <a href="http://barzilay.org">http://barzilay.org</a>/ Maze is Life! <hr /> Message: 2 Date: Mon, 11 Jun 2012 14:03:00 -0500 From: Robby Findler <robby@eecs.northwestern.edu> To: dev@racket-lang.org Cc: Harry Spier <vasishtha.spier@gmail.com>, racket List <users@racket-lang.org> Subject: Re: [racket] Feature request: multiple keys in sort Message-ID: <CAL3TdON0Hhs+RkepxMkX_2=5s3WbjXUybYmbAV5evJ0SqvPymg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 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@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@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: > ? ? ? ? ? ? ? ? ? ?<a href="http://barzilay.org">http://barzilay.org</a>/ ? ? ? ? ? ? ? ? ? Maze is Life! <hr /> Message: 3 Date: Mon, 11 Jun 2012 13:24:40 -0600 From: Jordan Schatz <jordan@noionlabs.com> To: Racket Users <users@racket-lang.org> Subject: [racket] unwrapping a list Message-ID: <871ull6493.fsf@noionlabs.com> Content-Type: text/plain Is there a way to unwrap or explode a list? I don't see it in the docs, but it seems like it would be a common thing. This is what I want to do: (define-values (year month day) (regexp-split #rx"/" "2012/06/06")) But regexp-split returns a list, not values, so I'd like to "unwrap" the list and just have the values... I can do it manually: (define tmp (regexp-split #rx"/" "2012/06/06")) (define year (first tmp)) (define month (second tmp)) (define day (third tmp)) But thats ugly. Being able to (let ([year month day (regexp-split #rx"/" "2012/06/06")]) ) Would be handy too... - Jordan <hr /> Message: 4 Date: Mon, 11 Jun 2012 20:30:02 +0100 From: Erik Silkensen <eriksilkensen@gmail.com> To: Jordan Schatz <jordan@noionlabs.com> Cc: Racket Users <users@racket-lang.org> Subject: Re: [racket] unwrapping a list Message-ID: <C9584DBF-9AC9-4167-B467-B9BBCA173A10@gmail.com> Content-Type: text/plain; charset=windows-1252 You could use match or match-let, e.g., (match-let ([(list year month day) (regexp-split #rx"/" "2012/06/06")]) ?) <a href="http://docs.racket-lang.org/reference/match.html">http://docs.racket-lang.org/reference/match.html</a> On Jun 11, 2012, at 8:24 PM, Jordan Schatz wrote: > > Is there a way to unwrap or explode a list? I don't see it in the docs, but it > seems like it would be a common thing. > > This is what I want to do: > > (define-values (year month day) > (regexp-split #rx"/" "2012/06/06")) > > But regexp-split returns a list, not values, so I'd like to "unwrap" the list > and just have the values... > > I can do it manually: > (define tmp (regexp-split #rx"/" "2012/06/06")) > (define year (first tmp)) > (define month (second tmp)) > (define day (third tmp)) > > But thats ugly. > > Being able to > (let ([year month day (regexp-split #rx"/" "2012/06/06")]) > ) > Would be handy too... > > - Jordan > > ____________________ > Racket Users list: > <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a> <hr /> Message: 5 Date: Mon, 11 Jun 2012 15:30:16 -0400 From: Eli Barzilay <eli@barzilay.org> To: Jordan Schatz <jordan@noionlabs.com> Cc: Racket Users <users@racket-lang.org> Subject: Re: [racket] unwrapping a list Message-ID: <20438.18248.302505.269345@winooski.ccs.neu.edu> Content-Type: text/plain; charset=us-ascii A few minutes ago, Jordan Schatz wrote: > > Is there a way to unwrap or explode a list? I don't see it in the > docs, but it seems like it would be a common thing. > > This is what I want to do: > > (define-values (year month day) > (regexp-split #rx"/" "2012/06/06")) > > But regexp-split returns a list, not values, so I'd like to "unwrap" > the list and just have the values... (match-define (list year month day) (regexp-split #rx"/" "2012/06/06")) > (let ([year month day (regexp-split #rx"/" "2012/06/06")]) > ) > Would be handy too... (match-let ([(list year month date) (regexp-split #rx"/" "2012/06/06")]) year) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: <a href="http://barzilay.org">http://barzilay.org</a>/ Maze is Life! <hr /> Message: 6 Date: Mon, 11 Jun 2012 15:30:49 -0400 From: Neil Van Dyke <neil@neilvandyke.org> To: Jordan Schatz <jordan@noionlabs.com> Cc: Racket Users <users@racket-lang.org> Subject: Re: [racket] unwrapping a list Message-ID: <4FD64769.7070505@neilvandyke.org> Content-Type: text/plain; charset=UTF-8; format=flowed (apply (lambda (year month day) (printf "Year: ~S Month: ~S Day: ~S\n" year month day)) (regexp-split #rx"/" "2012/06/06")) Neil V. End of users Digest, Vol 82, Issue 38 ************************************* </pre></blockquote></div></body></html>