Re: [racket-dev] check-match?
Thanks Asumu for merging and fixing my docs bug. Since this was my first time contributing, I figured I'd write up what the steps were for future first-time Racket hackers before I forget: http://jpolitz.github.com/blog/2012/11/21/racket-contributing-tutorial.html Cheers, Joe On Tue, Nov 20, 2012 at 8:41 AM, Robby Findler wrote: > I'm not sure how to find the right incantation to pull this down, but > this commit looks good to push to our repo. > > Robby > > On Tue, Nov 20, 2012 at 12:33 AM, Joe Gibbs Politz wrote: >> I think I've successfully sent a thingie to you: >> >> https://github.com/plt/racket/pull/171 >> >> Let me know if I Did It Wrong. This is the first time I've clicked >> the "Pull Request" button on Github. >> >> On Mon, Nov 19, 2012 at 10:12 PM, Joe Gibbs Politz wrote: >>> Gotcha. match-pred can be a separate thing. >>> >>> check-match can also let you use the identifiers bound in the match with an >>> optional third argument, which relies on more than match-pred anyway. >>> That's what I'm doing. >>> >>> >>> On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler >>> wrote: I think it is better to have a check-match since that way people are more likely to find it. Robby On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz wrote: >> (? P) => (lambda (x) (match x [P true] [_ false])) > > I like this quite a bit. It wouldn't be crazy to add it as > match-pred(icate) right next to match-lambda, match-let, and friends > > (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))). > > Then, for rackunit, it's just up to how much we like writing > > (check-match foo P) > > vs. > > (check-pred (match-pred P) foo) > > Both seem handy to me. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > >>> >>> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
I'm not sure how to find the right incantation to pull this down, but this commit looks good to push to our repo. Robby On Tue, Nov 20, 2012 at 12:33 AM, Joe Gibbs Politz wrote: > I think I've successfully sent a thingie to you: > > https://github.com/plt/racket/pull/171 > > Let me know if I Did It Wrong. This is the first time I've clicked > the "Pull Request" button on Github. > > On Mon, Nov 19, 2012 at 10:12 PM, Joe Gibbs Politz wrote: >> Gotcha. match-pred can be a separate thing. >> >> check-match can also let you use the identifiers bound in the match with an >> optional third argument, which relies on more than match-pred anyway. >> That's what I'm doing. >> >> >> On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler >> wrote: >>> >>> I think it is better to have a check-match since that way people are >>> more likely to find it. >>> >>> Robby >>> >>> On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz >>> wrote: >>> >> (? P) => (lambda (x) (match x [P true] [_ false])) >>> > >>> > I like this quite a bit. It wouldn't be crazy to add it as >>> > match-pred(icate) right next to match-lambda, match-let, and friends >>> > >>> > (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))). >>> > >>> > Then, for rackunit, it's just up to how much we like writing >>> > >>> > (check-match foo P) >>> > >>> > vs. >>> > >>> > (check-pred (match-pred P) foo) >>> > >>> > Both seem handy to me. >>> > >>> > _ >>> > Racket Developers list: >>> > http://lists.racket-lang.org/dev >>> > >> >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
I think I've successfully sent a thingie to you: https://github.com/plt/racket/pull/171 Let me know if I Did It Wrong. This is the first time I've clicked the "Pull Request" button on Github. On Mon, Nov 19, 2012 at 10:12 PM, Joe Gibbs Politz wrote: > Gotcha. match-pred can be a separate thing. > > check-match can also let you use the identifiers bound in the match with an > optional third argument, which relies on more than match-pred anyway. > That's what I'm doing. > > > On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler > wrote: >> >> I think it is better to have a check-match since that way people are >> more likely to find it. >> >> Robby >> >> On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz >> wrote: >> >> (? P) => (lambda (x) (match x [P true] [_ false])) >> > >> > I like this quite a bit. It wouldn't be crazy to add it as >> > match-pred(icate) right next to match-lambda, match-let, and friends >> > >> > (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))). >> > >> > Then, for rackunit, it's just up to how much we like writing >> > >> > (check-match foo P) >> > >> > vs. >> > >> > (check-pred (match-pred P) foo) >> > >> > Both seem handy to me. >> > >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
Gotcha. match-pred can be a separate thing. check-match can also let you use the identifiers bound in the match with an optional third argument, which relies on more than match-pred anyway. That's what I'm doing. On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler wrote: > I think it is better to have a check-match since that way people are > more likely to find it. > > Robby > > On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz > wrote: > >> (? P) => (lambda (x) (match x [P true] [_ false])) > > > > I like this quite a bit. It wouldn't be crazy to add it as > > match-pred(icate) right next to match-lambda, match-let, and friends > > ( > http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda)) > ). > > > > Then, for rackunit, it's just up to how much we like writing > > > > (check-match foo P) > > > > vs. > > > > (check-pred (match-pred P) foo) > > > > Both seem handy to me. > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
I think it is better to have a check-match since that way people are more likely to find it. Robby On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz wrote: >> (? P) => (lambda (x) (match x [P true] [_ false])) > > I like this quite a bit. It wouldn't be crazy to add it as > match-pred(icate) right next to match-lambda, match-let, and friends > (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))). > > Then, for rackunit, it's just up to how much we like writing > > (check-match foo P) > > vs. > > (check-pred (match-pred P) foo) > > Both seem handy to me. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
> (? P) => (lambda (x) (match x [P true] [_ false])) I like this quite a bit. It wouldn't be crazy to add it as match-pred(icate) right next to match-lambda, match-let, and friends ( http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda)) ). Then, for rackunit, it's just up to how much we like writing (check-match foo P) vs. (check-pred (match-pred P) foo) Both seem handy to me. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
rackunit has check-pred, of course. Robby On Mon, Nov 19, 2012 at 7:31 PM, Shriram Krishnamurthi wrote: > Predicates in general would be really awesome. I think the testing > infrastructure for Sperber's book (DMDA) has something like this. > > Making it lightweight is what matters most, whether through a new > match form or a more general predicate form. > > Shriram > > On Mon, Nov 19, 2012 at 8:25 PM, David Van Horn wrote: >> On 11/19/12 8:20 PM, Joe Gibbs Politz wrote: >>> >>> > Yeah, that is very nice! (It should begin with "check" not "test" >>> tho, right?) >>> >>> Indeed; Jonah was writing w.r.t plai, which uses test. Should use >>> check- in rackunit. >>> >>> I noticed that this also violates, from the rackunit docs: >>> >>> "Although checks are implemented as macros, which is necessary to grab >>> source location, they are conceptually functions. This means, for >>> instance, checks always evaluate their arguments." >>> >>> I suppose this should go in a separate section of "additional checks" or >>> some such? >> >> >> Maybe the right thing to do is make it lightweight to write predicates with >> match so that you don't even need a separate testing form? >> >> Something like (? P) => (lambda (x) (match x [P true] [_ false])) >> >> David >> >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
That might be nice, but a form for including a match pattern seems like something that would be really great to have. Robby On Mon, Nov 19, 2012 at 7:25 PM, David Van Horn wrote: > On 11/19/12 8:20 PM, Joe Gibbs Politz wrote: >> >> > Yeah, that is very nice! (It should begin with "check" not "test" >> tho, right?) >> >> Indeed; Jonah was writing w.r.t plai, which uses test. Should use >> check- in rackunit. >> >> I noticed that this also violates, from the rackunit docs: >> >> "Although checks are implemented as macros, which is necessary to grab >> source location, they are conceptually functions. This means, for >> instance, checks always evaluate their arguments." >> >> I suppose this should go in a separate section of "additional checks" or >> some such? > > > Maybe the right thing to do is make it lightweight to write predicates with > match so that you don't even need a separate testing form? > > Something like (? P) => (lambda (x) (match x [P true] [_ false])) > > David > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
Predicates in general would be really awesome. I think the testing infrastructure for Sperber's book (DMDA) has something like this. Making it lightweight is what matters most, whether through a new match form or a more general predicate form. Shriram On Mon, Nov 19, 2012 at 8:25 PM, David Van Horn wrote: > On 11/19/12 8:20 PM, Joe Gibbs Politz wrote: >> >> > Yeah, that is very nice! (It should begin with "check" not "test" >> tho, right?) >> >> Indeed; Jonah was writing w.r.t plai, which uses test. Should use >> check- in rackunit. >> >> I noticed that this also violates, from the rackunit docs: >> >> "Although checks are implemented as macros, which is necessary to grab >> source location, they are conceptually functions. This means, for >> instance, checks always evaluate their arguments." >> >> I suppose this should go in a separate section of "additional checks" or >> some such? > > > Maybe the right thing to do is make it lightweight to write predicates with > match so that you don't even need a separate testing form? > > Something like (? P) => (lambda (x) (match x [P true] [_ false])) > > David > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
I think you should just stick "(except @racket[check-], since its first/second argument is a match pattern)" or something like that into the docs in your pull request. Also test cases: I think there is a test suite for rackunit somewhere; let me know if you have trouble with it and I can add tests. Robby On Mon, Nov 19, 2012 at 7:20 PM, Joe Gibbs Politz wrote: >> Yeah, that is very nice! (It should begin with "check" not "test" tho, >> right?) > > Indeed; Jonah was writing w.r.t plai, which uses test. Should use check- in > rackunit. > > I noticed that this also violates, from the rackunit docs: > > "Although checks are implemented as macros, which is necessary to grab > source location, they are conceptually functions. This means, for instance, > checks always evaluate their arguments." > > I suppose this should go in a separate section of "additional checks" or > some such? > > > On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler > wrote: >> >> Yeah, that is very nice! (It should begin with "check" not "test" tho, >> right?) >> >> Robby >> >> >> On Monday, November 19, 2012, Matthias Felleisen wrote: >>> >>> >>> That is cute. Why don't you just create a pull request and Ryan can >>> integrate it into rackunit? -- Matthias >>> >>> >>> >>> >>> >>> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: >>> >>> > A small suggestion: >>> > >>> > I used roughly this macro (credit Jonah Kagan) recently to help me >>> > write some tests for parsing code that agnostic to which source position >>> > is >>> > generated in the parse: >>> > >>> > (define-syntax test/match >>> > (syntax-rules () >>> > [(test/match actual expected pred) >>> > (let ([actual-val actual]) >>> >(with-check-info* (list (make-check-actual actual-val) >>> >(make-check-expected 'expected)) >>> > (thunk (check-true (match actual-val >>> > [expected pred] >>> > [_ false])] >>> > >>> > [(test/match actual expected) >>> > (test/match actual expected true)])) >>> > >>> > Shriram remarked that he was surprised some sort of check-match wasn't >>> > in rackunit already. Is it worth adding something like this? >>> > >>> > I'm doing things like: >>> > >>> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ >>> > "foo" >>> > >>> > Where the structs s-block, s-num, and s-str all expect a srcloc as >>> > their first argument, but I don't care about it for these tests. >>> > >>> > The actual use is at: >>> > >>> > >>> > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 >>> > >>> > That file would be much, much uglier without this macro. >>> > >>> > Cheers, >>> > Joe P. >>> > >>> > _ >>> > Racket Developers list: >>> > http://lists.racket-lang.org/dev >>> > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
On 11/19/12 8:20 PM, Joe Gibbs Politz wrote: > Yeah, that is very nice! (It should begin with "check" not "test" tho, right?) Indeed; Jonah was writing w.r.t plai, which uses test. Should use check- in rackunit. I noticed that this also violates, from the rackunit docs: "Although checks are implemented as macros, which is necessary to grab source location, they are conceptually functions. This means, for instance, checks always evaluate their arguments." I suppose this should go in a separate section of "additional checks" or some such? Maybe the right thing to do is make it lightweight to write predicates with match so that you don't even need a separate testing form? Something like (? P) => (lambda (x) (match x [P true] [_ false])) David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
> Yeah, that is very nice! (It should begin with "check" not "test" tho, right?) Indeed; Jonah was writing w.r.t plai, which uses test. Should use check- in rackunit. I noticed that this also violates, from the rackunit docs: "Although checks are implemented as macros, which is necessary to grab source location, they are conceptually functions. This means, for instance, checks always evaluate their arguments." I suppose this should go in a separate section of "additional checks" or some such? On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler wrote: > Yeah, that is very nice! (It should begin with "check" not "test" tho, > right?) > > Robby > > > On Monday, November 19, 2012, Matthias Felleisen wrote: > >> >> That is cute. Why don't you just create a pull request and Ryan can >> integrate it into rackunit? -- Matthias >> >> >> >> >> >> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: >> >> > A small suggestion: >> > >> > I used roughly this macro (credit Jonah Kagan) recently to help me >> write some tests for parsing code that agnostic to which source position is >> generated in the parse: >> > >> > (define-syntax test/match >> > (syntax-rules () >> > [(test/match actual expected pred) >> > (let ([actual-val actual]) >> >(with-check-info* (list (make-check-actual actual-val) >> >(make-check-expected 'expected)) >> > (thunk (check-true (match actual-val >> > [expected pred] >> > [_ false])] >> > >> > [(test/match actual expected) >> > (test/match actual expected true)])) >> > >> > Shriram remarked that he was surprised some sort of check-match wasn't >> in rackunit already. Is it worth adding something like this? >> > >> > I'm doing things like: >> > >> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ >> "foo" >> > >> > Where the structs s-block, s-num, and s-str all expect a srcloc as >> their first argument, but I don't care about it for these tests. >> > >> > The actual use is at: >> > >> > >> https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 >> > >> > That file would be much, much uglier without this macro. >> > >> > Cheers, >> > Joe P. >> > >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
We use test in PLAI, and I suggested it in that context (eg, unification, where you don't care about the gensym'ed names of logic variables), which is probably why it got called that. On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler wrote: > Yeah, that is very nice! (It should begin with "check" not "test" tho, > right?) > > Robby > > > On Monday, November 19, 2012, Matthias Felleisen wrote: >> >> >> That is cute. Why don't you just create a pull request and Ryan can >> integrate it into rackunit? -- Matthias >> >> >> >> >> >> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: >> >> > A small suggestion: >> > >> > I used roughly this macro (credit Jonah Kagan) recently to help me write >> > some tests for parsing code that agnostic to which source position is >> > generated in the parse: >> > >> > (define-syntax test/match >> > (syntax-rules () >> > [(test/match actual expected pred) >> > (let ([actual-val actual]) >> >(with-check-info* (list (make-check-actual actual-val) >> >(make-check-expected 'expected)) >> > (thunk (check-true (match actual-val >> > [expected pred] >> > [_ false])] >> > >> > [(test/match actual expected) >> > (test/match actual expected true)])) >> > >> > Shriram remarked that he was surprised some sort of check-match wasn't >> > in rackunit already. Is it worth adding something like this? >> > >> > I'm doing things like: >> > >> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ >> > "foo" >> > >> > Where the structs s-block, s-num, and s-str all expect a srcloc as their >> > first argument, but I don't care about it for these tests. >> > >> > The actual use is at: >> > >> > >> > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 >> > >> > That file would be much, much uglier without this macro. >> > >> > Cheers, >> > Joe P. >> > >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
Yeah, that is very nice! (It should begin with "check" not "test" tho, right?) Robby On Monday, November 19, 2012, Matthias Felleisen wrote: > > That is cute. Why don't you just create a pull request and Ryan can > integrate it into rackunit? -- Matthias > > > > > > On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: > > > A small suggestion: > > > > I used roughly this macro (credit Jonah Kagan) recently to help me write > some tests for parsing code that agnostic to which source position is > generated in the parse: > > > > (define-syntax test/match > > (syntax-rules () > > [(test/match actual expected pred) > > (let ([actual-val actual]) > >(with-check-info* (list (make-check-actual actual-val) > >(make-check-expected 'expected)) > > (thunk (check-true (match actual-val > > [expected pred] > > [_ false])] > > > > [(test/match actual expected) > > (test/match actual expected true)])) > > > > Shriram remarked that he was surprised some sort of check-match wasn't > in rackunit already. Is it worth adding something like this? > > > > I'm doing things like: > > > > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ > "foo" > > > > Where the structs s-block, s-num, and s-str all expect a srcloc as their > first argument, but I don't care about it for these tests. > > > > The actual use is at: > > > > > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 > > > > That file would be much, much uglier without this macro. > > > > Cheers, > > Joe P. > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
I written things like this before, so something built-in would be useful to me too. David On 11/19/12 5:01 PM, Matthias Felleisen wrote: That is cute. Why don't you just create a pull request and Ryan can integrate it into rackunit? -- Matthias On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: A small suggestion: I used roughly this macro (credit Jonah Kagan) recently to help me write some tests for parsing code that agnostic to which source position is generated in the parse: (define-syntax test/match (syntax-rules () [(test/match actual expected pred) (let ([actual-val actual]) (with-check-info* (list (make-check-actual actual-val) (make-check-expected 'expected)) (thunk (check-true (match actual-val [expected pred] [_ false])] [(test/match actual expected) (test/match actual expected true)])) Shriram remarked that he was surprised some sort of check-match wasn't in rackunit already. Is it worth adding something like this? I'm doing things like: (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ "foo" Where the structs s-block, s-num, and s-str all expect a srcloc as their first argument, but I don't care about it for these tests. The actual use is at: https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 That file would be much, much uglier without this macro. Cheers, Joe P. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-match?
That is cute. Why don't you just create a pull request and Ryan can integrate it into rackunit? -- Matthias On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote: > A small suggestion: > > I used roughly this macro (credit Jonah Kagan) recently to help me write some > tests for parsing code that agnostic to which source position is generated in > the parse: > > (define-syntax test/match > (syntax-rules () > [(test/match actual expected pred) > (let ([actual-val actual]) >(with-check-info* (list (make-check-actual actual-val) >(make-check-expected 'expected)) > (thunk (check-true (match actual-val > [expected pred] > [_ false])] > > [(test/match actual expected) > (test/match actual expected true)])) > > Shriram remarked that he was surprised some sort of check-match wasn't in > rackunit already. Is it worth adding something like this? > > I'm doing things like: > > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ "foo" > > Where the structs s-block, s-num, and s-str all expect a srcloc as their > first argument, but I don't care about it for these tests. > > The actual use is at: > > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 > > That file would be much, much uglier without this macro. > > Cheers, > Joe P. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] check-match?
A small suggestion: I used roughly this macro (credit Jonah Kagan) recently to help me write some tests for parsing code that agnostic to which source position is generated in the parse: (define-syntax test/match (syntax-rules () [(test/match actual expected pred) (let ([actual-val actual]) (with-check-info* (list (make-check-actual actual-val) (make-check-expected 'expected)) (thunk (check-true (match actual-val [expected pred] [_ false])] [(test/match actual expected) (test/match actual expected true)])) Shriram remarked that he was surprised some sort of check-match wasn't in rackunit already. Is it worth adding something like this? I'm doing things like: (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ "foo" Where the structs s-block, s-num, and s-str all expect a srcloc as their first argument, but I don't care about it for these tests. The actual use is at: https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36 That file would be much, much uglier without this macro. Cheers, Joe P. _ Racket Developers list: http://lists.racket-lang.org/dev