[racket] unwrapping a list

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>