Re: [racket-dev] DrDr Feature Request
I noticed this functionality just now.. thanks a lot! On 08/08/2011 12:38 PM, Jay McCarthy wrote: > Your wish is my command. > > On Mon, Aug 8, 2011 at 10:00 AM, Robby Findler > wrote: >> PS: I'm also happy if this class of tests only emails the responsible >> person, and not the pusher. >> >> Robby >> >> On Mon, Aug 8, 2011 at 10:59 AM, Robby Findler >> wrote: >>> I like the two-times-in-a-row thought. >>> >>> FWIW, please try to avoid race conditions of the second kind. >>> >>> I think the drracket test suites are special because they fail >>> not-so-often and I don't actually know how to fix them. If either of >>> those weren't true then I'd say they should just not run in drdr. (So >>> the race-condition/using the same file thing fails this test.) >>> >>> Robby >>> >>> On Mon, Aug 8, 2011 at 10:56 AM, Vincent St-Amour >>> wrote: I love DrDr, but there's a small thing that annoys me about it. Some tests are prone to intermittent failures. For example, some benchmarks need to create a file, and several benchmarks share the same file, which leads to race conditions. Similarly, some DrRacket tests sometimes fail for focus reasons. So, whenever someone pushes, they may get failures from these tests, then have go look at the actual errors, and try to figure out if they actually broke something or not. (Or, they ignore these failures, which is bad.) Here are two potential solutions. Let's assume that I just pushed something, and a test started failing. - Have DrDr send me email for every push about the broken test for as long as it fails. If I get email more than once, it's likely that I actually broke something. If I only get email once, the problem went away on its own, and was likely an intermittent failure. - Have the possiblity to flag some tests as intermittent (something like `drdr:random'), and only report failures for these tests if they fail twice in a row. This would reduce the amount of noise, since I expect most of these tests to pass most of the time. Actual breakage would still be detected, since it's unlikely that such failures would go away on their own. Detection would happen one push late, but that shouldn't be too much of an issue. Or, maybe only notify the pusher after two failures in a row, but notify the responsible person right away. Any thoughts? Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
Your wish is my command. On Mon, Aug 8, 2011 at 10:00 AM, Robby Findler wrote: > PS: I'm also happy if this class of tests only emails the responsible > person, and not the pusher. > > Robby > > On Mon, Aug 8, 2011 at 10:59 AM, Robby Findler > wrote: >> I like the two-times-in-a-row thought. >> >> FWIW, please try to avoid race conditions of the second kind. >> >> I think the drracket test suites are special because they fail >> not-so-often and I don't actually know how to fix them. If either of >> those weren't true then I'd say they should just not run in drdr. (So >> the race-condition/using the same file thing fails this test.) >> >> Robby >> >> On Mon, Aug 8, 2011 at 10:56 AM, Vincent St-Amour >> wrote: >>> >>> I love DrDr, but there's a small thing that annoys me about it. >>> >>> Some tests are prone to intermittent failures. For example, some >>> benchmarks need to create a file, and several benchmarks share the >>> same file, which leads to race conditions. Similarly, some DrRacket >>> tests sometimes fail for focus reasons. >>> >>> So, whenever someone pushes, they may get failures from these tests, >>> then have go look at the actual errors, and try to figure out if they >>> actually broke something or not. >>> >>> (Or, they ignore these failures, which is bad.) >>> >>> Here are two potential solutions. Let's assume that I just pushed >>> something, and a test started failing. >>> >>> - Have DrDr send me email for every push about the broken test for as >>> long as it fails. If I get email more than once, it's likely that I >>> actually broke something. If I only get email once, the problem went >>> away on its own, and was likely an intermittent failure. >>> >>> - Have the possiblity to flag some tests as intermittent (something >>> like `drdr:random'), and only report failures for these tests if >>> they fail twice in a row. This would reduce the amount of noise, >>> since I expect most of these tests to pass most of the time. Actual >>> breakage would still be detected, since it's unlikely that such >>> failures would go away on their own. Detection would happen one push >>> late, but that shouldn't be too much of an issue. >>> >>> Or, maybe only notify the pusher after two failures in a row, but >>> notify the responsible person right away. >>> >>> Any thoughts? >>> >>> Vincent >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> >> > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
Could DrDr say "This build is not the latest" or "The latest push is 234234"? On 08/08/2011 11:37 AM, Jay McCarthy wrote: > It is useful to test all of them to find out when errors start. It > doesn't do the newest first, because then the calculation of "new > issue" wouldn't make any sense, because you wouldn't have the previous > push's tests. > > Jay > > On Mon, Aug 8, 2011 at 11:34 AM, Jon Rafkind wrote: >> Another request: could DrDr process the latest push first? Its a little >> annoying to get emails for tests that failed when the latest push fixes >> them but DrDr is so far behind. Is there any benefit to testing all the >> intermediate pushes? >> >> On 08/08/2011 09:56 AM, Vincent St-Amour wrote: >>> I love DrDr, but there's a small thing that annoys me about it. >>> >>> Some tests are prone to intermittent failures. For example, some >>> benchmarks need to create a file, and several benchmarks share the >>> same file, which leads to race conditions. Similarly, some DrRacket >>> tests sometimes fail for focus reasons. >>> >>> So, whenever someone pushes, they may get failures from these tests, >>> then have go look at the actual errors, and try to figure out if they >>> actually broke something or not. >>> >>> (Or, they ignore these failures, which is bad.) >>> >>> Here are two potential solutions. Let's assume that I just pushed >>> something, and a test started failing. >>> >>> - Have DrDr send me email for every push about the broken test for as >>> long as it fails. If I get email more than once, it's likely that I >>> actually broke something. If I only get email once, the problem went >>> away on its own, and was likely an intermittent failure. >>> >>> - Have the possiblity to flag some tests as intermittent (something >>> like `drdr:random'), and only report failures for these tests if >>> they fail twice in a row. This would reduce the amount of noise, >>> since I expect most of these tests to pass most of the time. Actual >>> breakage would still be detected, since it's unlikely that such >>> failures would go away on their own. Detection would happen one push >>> late, but that shouldn't be too much of an issue. >>> >>> Or, maybe only notify the pusher after two failures in a row, but >>> notify the responsible person right away. >>> >>> Any thoughts? >>> >>> Vincent >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
It is useful to test all of them to find out when errors start. It doesn't do the newest first, because then the calculation of "new issue" wouldn't make any sense, because you wouldn't have the previous push's tests. Jay On Mon, Aug 8, 2011 at 11:34 AM, Jon Rafkind wrote: > Another request: could DrDr process the latest push first? Its a little > annoying to get emails for tests that failed when the latest push fixes > them but DrDr is so far behind. Is there any benefit to testing all the > intermediate pushes? > > On 08/08/2011 09:56 AM, Vincent St-Amour wrote: >> I love DrDr, but there's a small thing that annoys me about it. >> >> Some tests are prone to intermittent failures. For example, some >> benchmarks need to create a file, and several benchmarks share the >> same file, which leads to race conditions. Similarly, some DrRacket >> tests sometimes fail for focus reasons. >> >> So, whenever someone pushes, they may get failures from these tests, >> then have go look at the actual errors, and try to figure out if they >> actually broke something or not. >> >> (Or, they ignore these failures, which is bad.) >> >> Here are two potential solutions. Let's assume that I just pushed >> something, and a test started failing. >> >> - Have DrDr send me email for every push about the broken test for as >> long as it fails. If I get email more than once, it's likely that I >> actually broke something. If I only get email once, the problem went >> away on its own, and was likely an intermittent failure. >> >> - Have the possiblity to flag some tests as intermittent (something >> like `drdr:random'), and only report failures for these tests if >> they fail twice in a row. This would reduce the amount of noise, >> since I expect most of these tests to pass most of the time. Actual >> breakage would still be detected, since it's unlikely that such >> failures would go away on their own. Detection would happen one push >> late, but that shouldn't be too much of an issue. >> >> Or, maybe only notify the pusher after two failures in a row, but >> notify the responsible person right away. >> >> Any thoughts? >> >> Vincent >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
This is a rare event (playing catchup like this) so I think it is probably best if we just let it catch up. Should be just a couple of more days (maybe a week) by my sketchy guesstimationizing. Robby On Mon, Aug 8, 2011 at 12:34 PM, Jon Rafkind wrote: > Another request: could DrDr process the latest push first? Its a little > annoying to get emails for tests that failed when the latest push fixes > them but DrDr is so far behind. Is there any benefit to testing all the > intermediate pushes? > > On 08/08/2011 09:56 AM, Vincent St-Amour wrote: >> I love DrDr, but there's a small thing that annoys me about it. >> >> Some tests are prone to intermittent failures. For example, some >> benchmarks need to create a file, and several benchmarks share the >> same file, which leads to race conditions. Similarly, some DrRacket >> tests sometimes fail for focus reasons. >> >> So, whenever someone pushes, they may get failures from these tests, >> then have go look at the actual errors, and try to figure out if they >> actually broke something or not. >> >> (Or, they ignore these failures, which is bad.) >> >> Here are two potential solutions. Let's assume that I just pushed >> something, and a test started failing. >> >> - Have DrDr send me email for every push about the broken test for as >> long as it fails. If I get email more than once, it's likely that I >> actually broke something. If I only get email once, the problem went >> away on its own, and was likely an intermittent failure. >> >> - Have the possiblity to flag some tests as intermittent (something >> like `drdr:random'), and only report failures for these tests if >> they fail twice in a row. This would reduce the amount of noise, >> since I expect most of these tests to pass most of the time. Actual >> breakage would still be detected, since it's unlikely that such >> failures would go away on their own. Detection would happen one push >> late, but that shouldn't be too much of an issue. >> >> Or, maybe only notify the pusher after two failures in a row, but >> notify the responsible person right away. >> >> Any thoughts? >> >> Vincent >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
Another request: could DrDr process the latest push first? Its a little annoying to get emails for tests that failed when the latest push fixes them but DrDr is so far behind. Is there any benefit to testing all the intermediate pushes? On 08/08/2011 09:56 AM, Vincent St-Amour wrote: > I love DrDr, but there's a small thing that annoys me about it. > > Some tests are prone to intermittent failures. For example, some > benchmarks need to create a file, and several benchmarks share the > same file, which leads to race conditions. Similarly, some DrRacket > tests sometimes fail for focus reasons. > > So, whenever someone pushes, they may get failures from these tests, > then have go look at the actual errors, and try to figure out if they > actually broke something or not. > > (Or, they ignore these failures, which is bad.) > > Here are two potential solutions. Let's assume that I just pushed > something, and a test started failing. > > - Have DrDr send me email for every push about the broken test for as > long as it fails. If I get email more than once, it's likely that I > actually broke something. If I only get email once, the problem went > away on its own, and was likely an intermittent failure. > > - Have the possiblity to flag some tests as intermittent (something > like `drdr:random'), and only report failures for these tests if > they fail twice in a row. This would reduce the amount of noise, > since I expect most of these tests to pass most of the time. Actual > breakage would still be detected, since it's unlikely that such > failures would go away on their own. Detection would happen one push > late, but that shouldn't be too much of an issue. > > Or, maybe only notify the pusher after two failures in a row, but > notify the responsible person right away. > > Any thoughts? > > Vincent > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
At Mon, 8 Aug 2011 11:06:30 -0500, Robby Findler wrote: > > On Mon, Aug 8, 2011 at 11:05 AM, Vincent St-Amour > wrote: > > At Mon, 8 Aug 2011 10:59:24 -0500, > > Robby Findler wrote: > >> FWIW, please try to avoid race conditions of the second kind. > > > > Some of these I can try to fix. But I don't think all intermittent > > failures fit in this category. > > Right. I'm saying this: if you know you have a race condition and you > know how to fix it, then it is better to fix it than to use a > mechanism like the one you're asking for. I agree. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
On Mon, Aug 8, 2011 at 11:05 AM, Vincent St-Amour wrote: > At Mon, 8 Aug 2011 10:59:24 -0500, > Robby Findler wrote: >> FWIW, please try to avoid race conditions of the second kind. > > Some of these I can try to fix. But I don't think all intermittent > failures fit in this category. Right. I'm saying this: if you know you have a race condition and you know how to fix it, then it is better to fix it than to use a mechanism like the one you're asking for. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
At Mon, 8 Aug 2011 10:59:24 -0500, Robby Findler wrote: > FWIW, please try to avoid race conditions of the second kind. Some of these I can try to fix. But I don't think all intermittent failures fit in this category. > I think the drracket test suites are special because they fail > not-so-often and I don't actually know how to fix them. If either of > those weren't true then I'd say they should just not run in drdr. (So > the race-condition/using the same file thing fails this test.) Running these tests in DrDr has the benefit of detecting actual breakage when it happens, so I don't think we should give up on this. > PS: I'm also happy if this class of tests only emails the responsible > person, and not the pusher. I like that, and it's probably simpler to implement. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
PS: I'm also happy if this class of tests only emails the responsible person, and not the pusher. Robby On Mon, Aug 8, 2011 at 10:59 AM, Robby Findler wrote: > I like the two-times-in-a-row thought. > > FWIW, please try to avoid race conditions of the second kind. > > I think the drracket test suites are special because they fail > not-so-often and I don't actually know how to fix them. If either of > those weren't true then I'd say they should just not run in drdr. (So > the race-condition/using the same file thing fails this test.) > > Robby > > On Mon, Aug 8, 2011 at 10:56 AM, Vincent St-Amour > wrote: >> >> I love DrDr, but there's a small thing that annoys me about it. >> >> Some tests are prone to intermittent failures. For example, some >> benchmarks need to create a file, and several benchmarks share the >> same file, which leads to race conditions. Similarly, some DrRacket >> tests sometimes fail for focus reasons. >> >> So, whenever someone pushes, they may get failures from these tests, >> then have go look at the actual errors, and try to figure out if they >> actually broke something or not. >> >> (Or, they ignore these failures, which is bad.) >> >> Here are two potential solutions. Let's assume that I just pushed >> something, and a test started failing. >> >> - Have DrDr send me email for every push about the broken test for as >> long as it fails. If I get email more than once, it's likely that I >> actually broke something. If I only get email once, the problem went >> away on its own, and was likely an intermittent failure. >> >> - Have the possiblity to flag some tests as intermittent (something >> like `drdr:random'), and only report failures for these tests if >> they fail twice in a row. This would reduce the amount of noise, >> since I expect most of these tests to pass most of the time. Actual >> breakage would still be detected, since it's unlikely that such >> failures would go away on their own. Detection would happen one push >> late, but that shouldn't be too much of an issue. >> >> Or, maybe only notify the pusher after two failures in a row, but >> notify the responsible person right away. >> >> Any thoughts? >> >> Vincent >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr Feature Request
I like the two-times-in-a-row thought. FWIW, please try to avoid race conditions of the second kind. I think the drracket test suites are special because they fail not-so-often and I don't actually know how to fix them. If either of those weren't true then I'd say they should just not run in drdr. (So the race-condition/using the same file thing fails this test.) Robby On Mon, Aug 8, 2011 at 10:56 AM, Vincent St-Amour wrote: > > I love DrDr, but there's a small thing that annoys me about it. > > Some tests are prone to intermittent failures. For example, some > benchmarks need to create a file, and several benchmarks share the > same file, which leads to race conditions. Similarly, some DrRacket > tests sometimes fail for focus reasons. > > So, whenever someone pushes, they may get failures from these tests, > then have go look at the actual errors, and try to figure out if they > actually broke something or not. > > (Or, they ignore these failures, which is bad.) > > Here are two potential solutions. Let's assume that I just pushed > something, and a test started failing. > > - Have DrDr send me email for every push about the broken test for as > long as it fails. If I get email more than once, it's likely that I > actually broke something. If I only get email once, the problem went > away on its own, and was likely an intermittent failure. > > - Have the possiblity to flag some tests as intermittent (something > like `drdr:random'), and only report failures for these tests if > they fail twice in a row. This would reduce the amount of noise, > since I expect most of these tests to pass most of the time. Actual > breakage would still be detected, since it's unlikely that such > failures would go away on their own. Detection would happen one push > late, but that shouldn't be too much of an issue. > > Or, maybe only notify the pusher after two failures in a row, but > notify the responsible person right away. > > Any thoughts? > > Vincent > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] DrDr Feature Request
I love DrDr, but there's a small thing that annoys me about it. Some tests are prone to intermittent failures. For example, some benchmarks need to create a file, and several benchmarks share the same file, which leads to race conditions. Similarly, some DrRacket tests sometimes fail for focus reasons. So, whenever someone pushes, they may get failures from these tests, then have go look at the actual errors, and try to figure out if they actually broke something or not. (Or, they ignore these failures, which is bad.) Here are two potential solutions. Let's assume that I just pushed something, and a test started failing. - Have DrDr send me email for every push about the broken test for as long as it fails. If I get email more than once, it's likely that I actually broke something. If I only get email once, the problem went away on its own, and was likely an intermittent failure. - Have the possiblity to flag some tests as intermittent (something like `drdr:random'), and only report failures for these tests if they fail twice in a row. This would reduce the amount of noise, since I expect most of these tests to pass most of the time. Actual breakage would still be detected, since it's unlikely that such failures would go away on their own. Detection would happen one push late, but that shouldn't be too much of an issue. Or, maybe only notify the pusher after two failures in a row, but notify the responsible person right away. Any thoughts? Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] keyword args static checking and optimization
Ah, right. Rats. Robby On Mon, Aug 8, 2011 at 10:25 AM, Matthew Flatt wrote: > At Mon, 8 Aug 2011 10:12:36 -0500, Robby Findler wrote: >> > Another possibility is to redirect the `set!' on `f' to the >> > underlying `proc', and somehow make the optimized call to `core' >> > happen only when `proc' is never mutated. Due to the order of macro >> > expansion, whether `f' is mutated is not necessarily known when a >> > call to `f' is expanded. The expansion of a call to `f' would have >> > to embed the condition that `proc' is not mutated. >> >> How about adding an extra indirection? That is, you can have core be a >> simple wrapper function that calls some other function, and have proc >> also call that. Then the set! can be redirected to this thing that >> both call (you'd probably have to wrap the right hand side of the set! >> in some kind of argument protocol adjustment thing but if we're >> set!'ing procedures maybe we should have to pay for that). > > A use of `f' in a position other than an application position expands > to just `proc'. If `f' is mutated to something other than a procedure, > those uses of `proc' need to see the new value, so `proc' cannot be a > wrapper. > > I considered redirecting a mutation of `f' to both `proc' and `core', > but I worry about turning an atomic assignment operation into two > steps. > > A non-application use of `f' could expand to `(get-f)' instead of > `proc', and maybe there's a way for a single assignment to adjust both > `core' and `(get-f)', but I don't quite see it --- at least not without > destroying the direct use of `core' that enables inlining in common > cases. > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] keyword args static checking and optimization
At Mon, 8 Aug 2011 10:12:36 -0500, Robby Findler wrote: > > Another possibility is to redirect the `set!' on `f' to the > > underlying `proc', and somehow make the optimized call to `core' > > happen only when `proc' is never mutated. Due to the order of macro > > expansion, whether `f' is mutated is not necessarily known when a > > call to `f' is expanded. The expansion of a call to `f' would have > > to embed the condition that `proc' is not mutated. > > How about adding an extra indirection? That is, you can have core be a > simple wrapper function that calls some other function, and have proc > also call that. Then the set! can be redirected to this thing that > both call (you'd probably have to wrap the right hand side of the set! > in some kind of argument protocol adjustment thing but if we're > set!'ing procedures maybe we should have to pay for that). A use of `f' in a position other than an application position expands to just `proc'. If `f' is mutated to something other than a procedure, those uses of `proc' need to see the new value, so `proc' cannot be a wrapper. I considered redirecting a mutation of `f' to both `proc' and `core', but I worry about turning an atomic assignment operation into two steps. A non-application use of `f' could expand to `(get-f)' instead of `proc', and maybe there's a way for a single assignment to adjust both `core' and `(get-f)', but I don't quite see it --- at least not without destroying the direct use of `core' that enables inlining in common cases. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] keyword args static checking and optimization
On Mon, Aug 8, 2011 at 10:05 AM, Matthew Flatt wrote: > [Moved to the dev list.] > > At Sat, 06 Aug 2011 07:25:00 -0400, Neil Van Dyke wrote: >> Feature request... I'd *really* like to see compile-time checking of >> keyword arguments whenever that is possible. >> >> If compiler knows what procedure will be called, and the procedure uses >> keyword args in the usual way, then I'd like the compiler to report an >> error when the call site, say, uses a keyword arg that the procedure >> doesn't support. Likewise with required keyword args that are missing. >> >> As a second feature request, would be nice if, when the compiler (or >> JIT) can determine the procedure, if it could optimize the keyword args >> the same as if they were positional args. I don't know how much the >> compiler/JIT is doing already, but the static error-checking that it >> misses make me suspect the compiler is not optimizing this. > > The compiler proper knows nothing about keyword functions and function > calls. They're implemented by macros and expanded away into plain > functions and applicable structures. > > > Instead, argument checking can be pushed into the macro expansion of > keyword arguments. The idea is that `(define id arguments>)' can bind `id' as syntax that checks and optimizes > first-order uses of `id'. > > In more detail, > > (define f (lambda (a [b 1] #:c c #:d [d 3]) )) > > expands to > > (define (core a have-b? b c have-d? d) > (let* ([b (if have-b? b 1)] > [d (if have-d? d 3)]) > )) > > (define proc > (make-keyword-procedure (lambda (core > > (define-syntax (f stx) > (if ... application looks ok? > (core ) ; direct call; no keyword checking or packaging > (begin > ... issue warning ... > (proc ; existing protocol > > so that > > (f 0 1 #:c 2) > > expands to > > (core 0 #t 1 2 #f #f) > > > The macro approach has some drawbacks: > > * It's not quite as general as a warning from the compiler's > optimization pass, which can detect some higher-order uses through > copy propagation and inlining. A first-order check covers most cases > in practice, though. > > * Macros don't compose as nicely. Because of the way that macro > expansion is ordered in a definition context, `define' can't force > the expansion of its right-hand size to check whether it expands to > `lambda'. Instead, `define' can only recognize immediate `lambda' > forms. Again, that's probably good enough to be useful in practice. > > * The `class' and `unit' forms expect `define' to bind a variable and > not syntax, because they rewrite definitions based on the connection > between an identifier with `define' and an identifier written in a > signature or a `public' clause. > > To avoid this problem, the `define' form can require some > cooperation from definition contexts. A definition context that is > implemented via `local-expand' declares its willing to work with the > non-variable expansion by giving its context representation the > `prop:liberal-define-context' property. The internal-definition > contexts that are built into `lambda, `let', etc., all set that > property, while the `class' and `unit' forms do not. > > * Reflection creates the usual sort of trouble: > > (define f (lambda (#:x x) ')) > (namespace-variable-value 'f #f #f > (variable-reference->namespace > (#%variable-reference))) > > I don't mind weakening reflection at this level; it seems ok to say > that `define' creates a syntax binding for keyword functions (in a > liberal definition context). > > * Mutation creates deep trouble: > > (define f (lambda (#:x x) )) > (set! f (lambda (#:y y) y)) > (f #:y 12) > > One option is to disallow `set!' on an identifier that is bound to a > keyword-accepting procedure. That seems awkward, and it seems like > it would compose badly. I'm not as willing to sacrifice `set!' as I > am to sacrifice reflection. > > Another possibility is to redirect the `set!' on `f' to the > underlying `proc', and somehow make the optimized call to `core' > happen only when `proc' is never mutated. Due to the order of macro > expansion, whether `f' is mutated is not necessarily known when a > call to `f' is expanded. The expansion of a call to `f' would have > to embed the condition that `proc' is not mutated. How about adding an extra indirection? That is, you can have core be a simple wrapper function that calls some other function, and have proc also call that. Then the set! can be redirected to this thing that both call (you'd probably have to wrap the right hand side of the set! in some kind of argument protocol adjustment thing but if we're set!'ing procedures maybe we should have to pay for that). > We already have `#%variable-reference' to reflect information about > variables into an expressi
Re: [racket-dev] [racket] keyword args static checking and optimization
[Moved to the dev list.] At Sat, 06 Aug 2011 07:25:00 -0400, Neil Van Dyke wrote: > Feature request... I'd *really* like to see compile-time checking of > keyword arguments whenever that is possible. > > If compiler knows what procedure will be called, and the procedure uses > keyword args in the usual way, then I'd like the compiler to report an > error when the call site, say, uses a keyword arg that the procedure > doesn't support. Likewise with required keyword args that are missing. > > As a second feature request, would be nice if, when the compiler (or > JIT) can determine the procedure, if it could optimize the keyword args > the same as if they were positional args. I don't know how much the > compiler/JIT is doing already, but the static error-checking that it > misses make me suspect the compiler is not optimizing this. The compiler proper knows nothing about keyword functions and function calls. They're implemented by macros and expanded away into plain functions and applicable structures. Instead, argument checking can be pushed into the macro expansion of keyword arguments. The idea is that `(define id )' can bind `id' as syntax that checks and optimizes first-order uses of `id'. In more detail, (define f (lambda (a [b 1] #:c c #:d [d 3]) )) expands to (define (core a have-b? b c have-d? d) (let* ([b (if have-b? b 1)] [d (if have-d? d 3)]) )) (define proc (make-keyword-procedure (lambda (core (define-syntax (f stx) (if ... application looks ok? (core ) ; direct call; no keyword checking or packaging (begin ... issue warning ... (proc ; existing protocol so that (f 0 1 #:c 2) expands to (core 0 #t 1 2 #f #f) The macro approach has some drawbacks: * It's not quite as general as a warning from the compiler's optimization pass, which can detect some higher-order uses through copy propagation and inlining. A first-order check covers most cases in practice, though. * Macros don't compose as nicely. Because of the way that macro expansion is ordered in a definition context, `define' can't force the expansion of its right-hand size to check whether it expands to `lambda'. Instead, `define' can only recognize immediate `lambda' forms. Again, that's probably good enough to be useful in practice. * The `class' and `unit' forms expect `define' to bind a variable and not syntax, because they rewrite definitions based on the connection between an identifier with `define' and an identifier written in a signature or a `public' clause. To avoid this problem, the `define' form can require some cooperation from definition contexts. A definition context that is implemented via `local-expand' declares its willing to work with the non-variable expansion by giving its context representation the `prop:liberal-define-context' property. The internal-definition contexts that are built into `lambda, `let', etc., all set that property, while the `class' and `unit' forms do not. * Reflection creates the usual sort of trouble: (define f (lambda (#:x x) ')) (namespace-variable-value 'f #f #f (variable-reference->namespace (#%variable-reference))) I don't mind weakening reflection at this level; it seems ok to say that `define' creates a syntax binding for keyword functions (in a liberal definition context). * Mutation creates deep trouble: (define f (lambda (#:x x) )) (set! f (lambda (#:y y) y)) (f #:y 12) One option is to disallow `set!' on an identifier that is bound to a keyword-accepting procedure. That seems awkward, and it seems like it would compose badly. I'm not as willing to sacrifice `set!' as I am to sacrifice reflection. Another possibility is to redirect the `set!' on `f' to the underlying `proc', and somehow make the optimized call to `core' happen only when `proc' is never mutated. Due to the order of macro expansion, whether `f' is mutated is not necessarily known when a call to `f' is expanded. The expansion of a call to `f' would have to embed the condition that `proc' is not mutated. We already have `#%variable-reference' to reflect information about variables into an expressions; to make it work in all definition contexts, `#%variable-reference' must be generalized to work with local variables, but that's a relatively minor change. Then, a `variable-reference-constant?' procedure can report the constantness of a variable. With those pieces, and when redirecting mutations of `f' to `proc', a call to `f' could expand to (if (variable-reference-constant? (#%variable-reference proc)) (core ) (proc .)) In some cases, especially for local bindings, the compiler can statically determine whether a
Re: [racket-dev] [plt] Push #23181: master branch updated
On Mon, Aug 8, 2011 at 2:26 AM, Eli Barzilay wrote: > Two days ago, Casey Klein wrote: >> >> Oh, I see. I like that. How do you feel about using the same style >> for contracts? For example: >> >> (define-judgment-form nats >> #:mode (sum I I O) >> #:contract (sum n n n) > > Not a party I'm familiar with, but separating the IOs from the types > seems bad. Can't they be specified together? > That could work: (define-judgment-form nats (sum [n I] [n I] [n O]) ) Or if you choose not to supply a contract: (define-judgment-form nats (sum I I O) ) I think you're right that something like this would be better. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
Two days ago, Casey Klein wrote: > > Oh, I see. I like that. How do you feel about using the same style > for contracts? For example: > > (define-judgment-form nats > #:mode (sum I I O) > #:contract (sum n n n) Not a party I'm familiar with, but separating the IOs from the types seems bad. Can't they be specified together? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
