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.
users-request at racket-lang.org wrote:
Send users mailing list submissions to
users at racket-lang.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.racket-lang.org/users/listinfo
or, via email, send a message with subject or body 'help' to
users-request at racket-lang.org
You can reach the person managing the list at
users-owner at racket-lang.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
[Racket Users list:
http://lists.racket-lang.org/users]
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)
_____________________________________________
Message: 1
Date: Mon, 11 Jun 2012 14:58:47 -0400
From: Eli Barzilay <eli at barzilay.org>
To: Robby Findler <robby at eecs.northwestern.edu>
Cc: Harry Spier <vasishtha.spier at gmail.com>, racket List
<users at racket-lang.org>
Subject: Re: [racket] Feature request: multiple keys in sort
Message-ID: <20438.16359.371830.465004 at 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 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!
_____________________________________________
Message: 2
Date: Mon, 11 Jun 2012 14:03:00 -0500
From: Robby Findler <robby at eecs.northwestern.edu>
To: dev at racket-lang.org
Cc: Harry Spier <vasishtha.spier at gmail.com>, racket List
<users at racket-lang.org>
Subject: Re: [racket] Feature request: multiple keys in sort
Message-ID:
<CAL3TdON0Hhs+RkepxMkX_2=5s3WbjXUybYmbAV5evJ0SqvPymg at 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 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!
_____________________________________________
Message: 3
Date: Mon, 11 Jun 2012 13:24:40 -0600
From: Jordan Schatz <jordan at noionlabs.com>
To: Racket Users <users at racket-lang.org>
Subject: [racket] unwrapping a list
Message-ID: <871ull6493.fsf at 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
_____________________________________________
Message: 4
Date: Mon, 11 Jun 2012 20:30:02 +0100
From: Erik Silkensen <eriksilkensen at gmail.com>
To: Jordan Schatz <jordan at noionlabs.com>
Cc: Racket Users <users at racket-lang.org>
Subject: Re: [racket] unwrapping a list
Message-ID: <C9584DBF-9AC9-4167-B467-B9BBCA173A10 at 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")])
?)
http://docs.racket-lang.org/reference/match.html
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:
>http://lists.racket-lang.org/users
_____________________________________________
Message: 5
Date: Mon, 11 Jun 2012 15:30:16 -0400
From: Eli Barzilay <eli at barzilay.org>
To: Jordan Schatz <jordan at noionlabs.com>
Cc: Racket Users <users at racket-lang.org>
Subject: Re: [racket] unwrapping a list
Message-ID: <20438.18248.302505.269345 at 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:
http://barzilay.org/ Maze is Life!
_____________________________________________
Message: 6
Date: Mon, 11 Jun 2012 15:30:49 -0400
From: Neil Van Dyke <neil at neilvandyke.org>
To: Jordan Schatz <jordan at noionlabs.com>
Cc: Racket Users <users at racket-lang.org>
Subject: Re: [racket] unwrapping a list
Message-ID: <4FD64769.7070505 at 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
*************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120611/1ff15850/attachment-0001.html>