Re: [racket-dev] Wow; racket master at least 2x faster than 5.3.1 on my rb tree benchmark?
Score another one for random testing! :) On Sun, Nov 18, 2012 at 10:26 PM, Danny Yoo d...@hashcollision.org wrote: On Sun, Nov 18, 2012 at 4:24 PM, Pierpaolo Bernardi olopie...@gmail.com wrote: How does compare to builtin mutable hashes? The following code represents a rough hashtable equivalent of what my rb code would be enabling (quick search for word by position): ;; We might be curious as to the overhead of the tree structure. ;; (of course, it's worth it because we are dealing with a dynamic set here.) ;; Still, let's compare with inserting into a native hash: (printf just for comparison: inserting in a native hash:\n) (let ([ht (make-hash)]) (time (for/fold ([acc 0]) ([word (in-list (force all-words))]) (hash-set! ht acc word) (+ acc (string-length word) It's also useful to compare this vs the existing splay tree approach in syntax-color/token-tree: (printf just for comparison: inserting in the original token tree:\n) (let ([t (new token-tree%)]) (time (for ([word (in-list (force all-words))]) (insert-last-spec! t (string-length word) word Here's the output of the insertion benchmark: ;; (from the rb-tree insertion) inserting 235886 words at the end... cpu time: 204 real time: 205 gc time: 0 just for comparison: inserting in a native hash: cpu time: 108 real time: 107 gc time: 0 just for comparison: inserting in the original token tree: cpu time: 51 real time: 51 gc time: 0 So compared to the rb-tree version, insertions into the hashtable are about twice as fast. And as one might expect, the splay tree bulk insertion is the fastest: it doesn't deal with balance at insertion time and can it delay that work until we start searching the structure. The rb-tree (as well as the original splay code) allows for much more flexible searches and dynamic updates into the sequence structure than the hash, so it's definitely worth the extra complexity. My conjecture is that the non-allocating nature of the rb-tree, as well as its always-balanced structure, will be worth the cost of the extra insertion time vs splays. I just hope I can show it! :) I'll see tomorrow when I code up a token-tree% implementation and start measuring times in DrRacket. I just got done with the fundamental rb-tree data structures this evening. Thank goodness Robby strongly recommended me to write a randomized testing approach. It caught a lot of things I hadn't even considered. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
I think it is probably best to have the OpenBSD port be a faithful match to 5.3.1. This isn't a major bug and hopefully you'll just get the fix in 5.3.2 or whatever the next version is called in 2-3 months. Does that sound ok to you? Robby On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 03:40, Robby Findler wrote: On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto neil.toro...@gmail.com wrote: It's a problem with the contract boundary. The examples work fine in Typed Racket. The problem type is this: (: flomap-transform (case- (flomap Flomap-Transform - flomap) (flomap Flomap-Transform Integer Integer Integer Integer - flomap))) The contract system claims that `flomap-transform' breaks its own contract. This is clearly bogus, so TR must be generating the wrong contract for it. Still, I should have caught this, and I apologize. I'll do penance by... writing a bug report? Probably not enough. Penance is an antiquated concept. We should do away with it. :) But if you feel bad enough to make a small program that demonstrates the problem that would be a contribution to it's solution! Thanks for to catch the bug guys!. Please send me a mail when you fix the bug and I'll add the patches to the OpenBSD port. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket installs more files on amd64 than on i386
On 11/19/12 19:21, Robby Findler wrote: I think it is probably best to have the OpenBSD port be a faithful match to 5.3.1. This isn't a major bug and hopefully you'll just get the fix in 5.3.2 or whatever the next version is called in 2-3 months. Does that sound ok to you? Temporally I'll remove the files affected from the PLIST (the list of files of the package), with this I can avoid the differences between archs. When the bug is fixed, I'll decide if the patch is too invasive or not for add to the port. Obviously this bug isn't a big problem for me :) OpenBSD will release the next version at May 1 and IIRC the frozen of the CVS will occur in February. I want do racket a official package for the next release, so I need fix or at least add a note about the known bugs. Robby On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 03:40, Robby Findler wrote: On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto neil.toro...@gmail.com wrote: It's a problem with the contract boundary. The examples work fine in Typed Racket. The problem type is this: (: flomap-transform (case- (flomap Flomap-Transform - flomap) (flomap Flomap-Transform Integer Integer Integer Integer - flomap))) The contract system claims that `flomap-transform' breaks its own contract. This is clearly bogus, so TR must be generating the wrong contract for it. Still, I should have caught this, and I apologize. I'll do penance by... writing a bug report? Probably not enough. Penance is an antiquated concept. We should do away with it. :) But if you feel bad enough to make a small program that demonstrates the problem that would be a contribution to it's solution! Thanks for to catch the bug guys!. Please send me a mail when you fix the bug and I'll add the patches to the OpenBSD port. _ 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
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
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?
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] Racket installs more files on amd64 than on i386
Oh, I see. If you really need the lists of files to be the same, it is probably best to make both versions have the files (altho don't different architectures have different sets of files in general?). Probably you'll be breaking the distro if you remove files. Robby On Monday, November 19, 2012, Juan Francisco Cantero Hurtado wrote: On 11/19/12 19:21, Robby Findler wrote: I think it is probably best to have the OpenBSD port be a faithful match to 5.3.1. This isn't a major bug and hopefully you'll just get the fix in 5.3.2 or whatever the next version is called in 2-3 months. Does that sound ok to you? Temporally I'll remove the files affected from the PLIST (the list of files of the package), with this I can avoid the differences between archs. When the bug is fixed, I'll decide if the patch is too invasive or not for add to the port. Obviously this bug isn't a big problem for me :) OpenBSD will release the next version at May 1 and IIRC the frozen of the CVS will occur in February. I want do racket a official package for the next release, so I need fix or at least add a note about the known bugs. Robby On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On 11/19/12 03:40, Robby Findler wrote: On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto neil.toro...@gmail.com wrote: It's a problem with the contract boundary. The examples work fine in Typed Racket. The problem type is this: (: flomap-transform (case- (flomap Flomap-Transform - flomap) (flomap Flomap-Transform Integer Integer Integer Integer - flomap))) The contract system claims that `flomap-transform' breaks its own contract. This is clearly bogus, so TR must be generating the wrong contract for it. Still, I should have caught this, and I apologize. I'll do penance by... writing a bug report? Probably not enough. Penance is an antiquated concept. We should do away with it. :) But if you feel bad enough to make a small program that demonstrates the problem that would be a contribution to it's solution! Thanks for to catch the bug guys!. Please send me a mail when you fix the bug and I'll add the patches to the OpenBSD port. _ Racket Developers list: http://lists.racket-lang.org/**dev 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 ro...@eecs.northwestern.edu 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?) 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 ro...@eecs.northwestern.eduwrote: 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?
I think you should just stick (except @racket[check-whatever], 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 j...@cs.brown.edu 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 ro...@eecs.northwestern.edu 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?
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 dvanh...@ccs.neu.edu 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?
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 dvanh...@ccs.neu.edu 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?
rackunit has check-pred, of course. Robby On Mon, Nov 19, 2012 at 7:31 PM, Shriram Krishnamurthi s...@cs.brown.edu 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 dvanh...@ccs.neu.edu 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?
(? 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=matchq=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?
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 j...@cs.brown.edu 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=matchq=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 ro...@eecs.northwestern.eduwrote: 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 j...@cs.brown.edu 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=matchq=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 j...@cs.brown.edu 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 ro...@eecs.northwestern.edu 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 j...@cs.brown.edu 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=matchq=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
