Re: [racket-dev] provide expand-clause in racket/private/for.rkt
As far as I can see, exporting `expand-clause` is ok. Ideally, I think it should be exported from a new `racket/for-transform` library, instead of used directly from `racket/private/for`. Also, `expand-for-clause` might be a better name. At Fri, 6 Sep 2013 00:45:40 -0400, Stephen Chang wrote: Hi dev, I would like to provide (for-syntax) the expand-clause function in racket/private/for.rkt. Would this cause any problems? Would anyone object to this? I have an implementation of for/X in my generic-bind library that uses expand-clause and with it, the generic-bind ~for forms are as fast, sometimes a little faster, than racket's for/X in some preliminary testing. (Without access to expand-clause, sequence traversal is slow --- the current planet-available version of my library uses sequence-generate and is twice as slow.) The sometimes a little faster is likely in part due to less error-checking, but my implementation passes all the for/X unit tests and so as is, it can reasonably be used in place of for/X. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Module Browser not a plugin/tool
Hi, I just tried making a instance of insert-large-letters as a tool. I just copied the code and added the tools stuff. Seemed to work OK, but - I turned it into normal racket as I didn't have time to learn typed racket. - I'm not confident enough with the core of DrRacket to remove the 'insert-large-letters' code without messing something else up. I'm doing this as a learning exercise for the tools, but I may try get-defns[1] and module browser[2] at some point. [1] personally not a big fan of drop down menus - I like the tree thingy you see in other IDEs [2] to make Dr start quicker on slow machines. Cheers, Stephen -- Stephen De Gabrielle http://www.degabrielle.name/stephen On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure the module browser was before the plugin api, but probably it wasn't. I think all three of those could be tools, but it is an accident of history (and of who implemented them...) that they aren't. Probably they should be. We might even save some startup time by disabling the module browser. Robby On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, looking through the source I've noticed the module browser is not a tool, I'm guessing this is because it preceded the introduction of the plugins mechanism? Check Syntax is a tool, but insert-large-letters.rkt and get-defn's are not? is there a defined criteria? or is the arrangement historic/ Kind Regards, Stephen _ Racket Developers list: http://lists.racket-lang.org/dev bitmap-message.rkt Description: Binary data info.rkt Description: Binary data tool.rkt Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Module Browser not a plugin/tool
Ugh - the list scrubbed my attachments. I'm guessing my options are to submit pull request or make a planet package. s. On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, I just tried making a instance of insert-large-letters as a tool. I just copied the code and added the tools stuff. Seemed to work OK, but - I turned it into normal racket as I didn't have time to learn typed racket. - I'm not confident enough with the core of DrRacket to remove the 'insert-large-letters' code without messing something else up. I'm doing this as a learning exercise for the tools, but I may try get-defns[1] and module browser[2] at some point. [1] personally not a big fan of drop down menus - I like the tree thingy you see in other IDEs [2] to make Dr start quicker on slow machines. Cheers, Stephen -- Stephen De Gabrielle http://www.degabrielle.name/stephen On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure the module browser was before the plugin api, but probably it wasn't. I think all three of those could be tools, but it is an accident of history (and of who implemented them...) that they aren't. Probably they should be. We might even save some startup time by disabling the module browser. Robby On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, looking through the source I've noticed the module browser is not a tool, I'm guessing this is because it preceded the introduction of the plugins mechanism? Check Syntax is a tool, but insert-large-letters.rkt and get-defn's are not? is there a defined criteria? or is the arrangement historic/ Kind Regards, Stephen _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Module Browser not a plugin/tool
I got the attachments, FWIW. Probably best, however, if someone were to submit a pull request with the code still in TR and with the appropriate removal of the current implementation. Otherwise, I think it has served its purpose as a learning experiment and that's seems excellent. Robby On Fri, Sep 6, 2013 at 8:32 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Ugh - the list scrubbed my attachments. I'm guessing my options are to submit pull request or make a planet package. s. On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, I just tried making a instance of insert-large-letters as a tool. I just copied the code and added the tools stuff. Seemed to work OK, but - I turned it into normal racket as I didn't have time to learn typed racket. - I'm not confident enough with the core of DrRacket to remove the 'insert-large-letters' code without messing something else up. I'm doing this as a learning exercise for the tools, but I may try get-defns[1] and module browser[2] at some point. [1] personally not a big fan of drop down menus - I like the tree thingy you see in other IDEs [2] to make Dr start quicker on slow machines. Cheers, Stephen -- Stephen De Gabrielle http://www.degabrielle.name/stephen On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure the module browser was before the plugin api, but probably it wasn't. I think all three of those could be tools, but it is an accident of history (and of who implemented them...) that they aren't. Probably they should be. We might even save some startup time by disabling the module browser. Robby On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, looking through the source I've noticed the module browser is not a tool, I'm guessing this is because it preceded the introduction of the plugins mechanism? Check Syntax is a tool, but insert-large-letters.rkt and get-defn's are not? is there a defined criteria? or is the arrangement historic/ Kind Regards, Stephen _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Module Browser not a plugin/tool
thanks. http://planet.racket-lang.org/display.ss?package=insert-large-letters.pltowner=spdegabrielle -- Stephen De Gabrielle http://www.degabrielle.name/stephen On Fri, Sep 6, 2013 at 2:35 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I got the attachments, FWIW. Probably best, however, if someone were to submit a pull request with the code still in TR and with the appropriate removal of the current implementation. Otherwise, I think it has served its purpose as a learning experiment and that's seems excellent. Robby On Fri, Sep 6, 2013 at 8:32 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Ugh - the list scrubbed my attachments. I'm guessing my options are to submit pull request or make a planet package. s. On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, I just tried making a instance of insert-large-letters as a tool. I just copied the code and added the tools stuff. Seemed to work OK, but - I turned it into normal racket as I didn't have time to learn typed racket. - I'm not confident enough with the core of DrRacket to remove the 'insert-large-letters' code without messing something else up. I'm doing this as a learning exercise for the tools, but I may try get-defns[1] and module browser[2] at some point. [1] personally not a big fan of drop down menus - I like the tree thingy you see in other IDEs [2] to make Dr start quicker on slow machines. Cheers, Stephen -- Stephen De Gabrielle http://www.degabrielle.name/stephen On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure the module browser was before the plugin api, but probably it wasn't. I think all three of those could be tools, but it is an accident of history (and of who implemented them...) that they aren't. Probably they should be. We might even save some startup time by disabling the module browser. Robby On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, looking through the source I've noticed the module browser is not a tool, I'm guessing this is because it preceded the introduction of the plugins mechanism? Check Syntax is a tool, but insert-large-letters.rkt and get-defn's are not? is there a defined criteria? or is the arrangement historic/ Kind Regards, Stephen _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
#lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than (define (fish? v) (or (red? v) (blue? v))) (let () (define (red? v) ) (define (blue? v) ) 5) At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf ~v/n (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf ~v\n result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. I had the same thought process as Carl. I now understand the behavior but I don't understand why it's needed? It seems kind of arbitrary since no other form allows multiple internal def contexts in the body like this. Is there a practical example? On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund c...@ccs.neu.edu wrote: Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than
Re: [racket-dev] tests not being run?
Ah - thank you! I think I finally understand how this works. To make sure, I query the props like this: ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt mzc -k ~s This tells DrDr to make sure the file compiles without error, but don't run. ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/file/main.rkt This is empty, telling DrDr to not do anything with this file - no compilation, no running, no reporting. ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt props: no `drdr:command-line' property for pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt This tells DrDr to do the default action, which is raco test ~s. Is this correct? Thanks, Dave On 09/05/2013 08:40 AM, Jay McCarthy wrote: On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson david.vander...@gmail.com mailto:david.vander...@gmail.com wrote: I totally missed pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt, but it looks like DrDr is running that with 'mzc -k _' - doesn't that just compile it? Yes, the intention there is to run the tests individually but test that the all runner works There is also a file/main.rkt that runs all the file/ tests, but that file doesn't show up in DrDr. That means that it is disabled, probably because it was intended to just run each file separately I'm more confused now. Does DrDr automatically run a main.rkt file if it's present? Whether DrDr runs a file is different on a file-by-file basis via the props database. For this file... Thanks, Dave On 09/04/2013 01:58 PM, Robby Findler wrote: I think it makes more sense to change those 'main' modules into 'test' modules, but I'm not positive. Robby On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson david.vander...@gmail.com mailto:david.vander...@gmail.com wrote: It looks to me like most of the tests in racket/pkgs/racket-pkgs/racket-test/tests/file/* are not being run by DrDr. I think DrDr is running them with 'raco test _' while the files mostly need to be run as 'racket _'. Am I missing something? If not, should I fix the files to be run with 'raco test _'? Thanks, Dave _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu mailto:j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay http://faculty.cs.byu.edu/%7Ejay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
They have to be separate internal definition contexts in order for #:break and #:final to be able to stop execution before the definitions themselves get run. Carl Eastlund On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang stch...@ccs.neu.edu wrote: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. I had the same thought process as Carl. I now understand the behavior but I don't understand why it's needed? It seems kind of arbitrary since no other form allows multiple internal def contexts in the body like this. Is there a practical example? On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund c...@ccs.neu.edu wrote: Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a
Re: [racket-dev] provide expand-clause in racket/private/for.rkt
On Fri, Sep 6, 2013 at 7:54 AM, Matthew Flatt mfl...@cs.utah.edu wrote: As far as I can see, exporting `expand-clause` is ok. Ideally, I think it should be exported from a new `racket/for-transform` library, instead of used directly from `racket/private/for`. Also, `expand-for-clause` might be a better name. Ok I will add it. Thanks. At Fri, 6 Sep 2013 00:45:40 -0400, Stephen Chang wrote: Hi dev, I would like to provide (for-syntax) the expand-clause function in racket/private/for.rkt. Would this cause any problems? Would anyone object to this? I have an implementation of for/X in my generic-bind library that uses expand-clause and with it, the generic-bind ~for forms are as fast, sometimes a little faster, than racket's for/X in some preliminary testing. (Without access to expand-clause, sequence traversal is slow --- the current planet-available version of my library uses sequence-generate and is twice as slow.) The sometimes a little faster is likely in part due to less error-checking, but my implementation passes all the for/X unit tests and so as is, it can reasonably be used in place of for/X. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
It's useful when the condition for loop termination and the value of the loop body both depend on some derived computation from the sequence elements: (for/list ([x (in-stream S)]) (define y (f x)) #:break (g? y) (h y)) Ok I see, thanks. It does make things easier to read when the break expression becomes too large to fit on one line. So is the reason why #:when and #:unless can't be used the same way because there already exist when and unless forms? Carl Eastlund On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang stch...@ccs.neu.edu wrote: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. I had the same thought process as Carl. I now understand the behavior but I don't understand why it's needed? It seems kind of arbitrary since no other form allows multiple internal def contexts in the body like this. Is there a practical example? On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund c...@ccs.neu.edu wrote: Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the
Re: [racket-dev] split-for-body from syntax/for-body
Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: Among the bodys, besides stopping the iteration and preventing later bodyevaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than (define (fish? v) (or (red? v) (blue? v))) (let () (define (red? v) ) (define (blue? v) ) 5) At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses
Re: [racket-dev] provide expand-clause in racket/private/for.rkt
Now that you've pushed this, it occurs to me why it's probably unsafe: some `in-...' forms expand to unsafe operations, right? If I'm right about that, then we should probably move the function to `racket/unsafe/for-transform' and protect the export. (Or, since I see that you put the library in `syntax/for-transform', maybe `syntax/unsafe/for-transform'?) At Fri, 6 Sep 2013 14:44:20 -0400, Stephen Chang wrote: On Fri, Sep 6, 2013 at 7:54 AM, Matthew Flatt mfl...@cs.utah.edu wrote: As far as I can see, exporting `expand-clause` is ok. Ideally, I think it should be exported from a new `racket/for-transform` library, instead of used directly from `racket/private/for`. Also, `expand-for-clause` might be a better name. Ok I will add it. Thanks. At Fri, 6 Sep 2013 00:45:40 -0400, Stephen Chang wrote: Hi dev, I would like to provide (for-syntax) the expand-clause function in racket/private/for.rkt. Would this cause any problems? Would anyone object to this? I have an implementation of for/X in my generic-bind library that uses expand-clause and with it, the generic-bind ~for forms are as fast, sometimes a little faster, than racket's for/X in some preliminary testing. (Without access to expand-clause, sequence traversal is slow --- the current planet-available version of my library uses sequence-generate and is twice as slow.) The sometimes a little faster is likely in part due to less error-checking, but my implementation passes all the for/X unit tests and so as is, it can reasonably be used in place of for/X. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
On Fri, Sep 6, 2013 at 2:43 PM, Stephen Chang stch...@ccs.neu.edu wrote: On Fri, Sep 6, 2013 at 2:36 PM, Carl Eastlund c...@ccs.neu.edu wrote: They have to be separate internal definition contexts in order for #:break and #:final to be able to stop execution before the definitions themselves get run. Hmm, ok. I guess my question was why does one need #:final and #:break in the body like that? It's useful when the condition for loop termination and the value of the loop body both depend on some derived computation from the sequence elements: (for/list ([x (in-stream S)]) (define y (f x)) #:break (g? y) (h y)) Carl Eastlund On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang stch...@ccs.neu.edu wrote: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. I had the same thought process as Carl. I now understand the behavior but I don't understand why it's needed? It seems kind of arbitrary since no other form allows multiple internal def contexts in the body like this. Is there a practical example? On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund c...@ccs.neu.edu wrote: Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: Among the bodys, besides stopping the iteration and preventing later body evaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context. So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue))
Re: [racket-dev] tests not being run?
All correct On Fri, Sep 6, 2013 at 12:34 PM, David Vanderson david.vander...@gmail.comwrote: Ah - thank you! I think I finally understand how this works. To make sure, I query the props like this: ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt mzc -k ~s This tells DrDr to make sure the file compiles without error, but don't run. ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/file/main.rkt This is empty, telling DrDr to not do anything with this file - no compilation, no running, no reporting. ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt props: no `drdr:command-line' property for pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt This tells DrDr to do the default action, which is raco test ~s. Is this correct? Thanks, Dave On 09/05/2013 08:40 AM, Jay McCarthy wrote: On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson david.vander...@gmail.com wrote: I totally missed pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt, but it looks like DrDr is running that with 'mzc -k _' - doesn't that just compile it? Yes, the intention there is to run the tests individually but test that the all runner works There is also a file/main.rkt that runs all the file/ tests, but that file doesn't show up in DrDr. That means that it is disabled, probably because it was intended to just run each file separately I'm more confused now. Does DrDr automatically run a main.rkt file if it's present? Whether DrDr runs a file is different on a file-by-file basis via the props database. For this file... Thanks, Dave On 09/04/2013 01:58 PM, Robby Findler wrote: I think it makes more sense to change those 'main' modules into 'test' modules, but I'm not positive. Robby On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson david.vander...@gmail.com wrote: It looks to me like most of the tests in racket/pkgs/racket-pkgs/racket-test/tests/file/* are not being run by DrDr. I think DrDr is running them with 'raco test _' while the files mostly need to be run as 'racket _'. Am I missing something? If not, should I fix the files to be run with 'raco test _'? Thanks, Dave _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than (define (fish? v) (or (red? v) (blue? v))) (let () (define (red? v) ) (define (blue? v) ) 5) At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf ~v/n (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf ~v\n result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than (define (fish? v) (or (red? v) (blue? v))) (let () (define (red? v) ) (define (blue? v) ) 5) At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf ~v/n (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf ~v\n result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] split-for-body from syntax/for-body
Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf ~v/n (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf ~v\n result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
Sorry that I forgot to add the `let` while turning the code you sent into a full example. Here's another try. #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/fixed/not clauses pre ... result) (for clauses pre ... (printf ~v\n (let () result (for/print/fixed/not ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf ~v\n (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: #lang racket/base (require (for-syntax racket/base syntax/parse syntax/for-body)) (define-syntax (for/print/good stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) (syntax (for clauses pre ... (printf ~v\n (let () post ...)])) (define-syntax-rule (for/print/bad clauses pre ... result) (for clauses pre ... (printf ~v\n result))) ;; Try changing to for/print/bad: (for/print/good ([i 1]) (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) (eq? v 'red)) (define (blue? v) (eq? v 'blue)) (fish? i))) At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The issue is `begin` splicing. The `result` form could be a `begin` form that contains definitions that are referenced by a preceding forms. For example, given (define (fish? v) (or (red? v) (blue? v))) (begin (define (red? v) ) (define (blue? v) ) 5) With `begin` splicing, that turns into (define (fish? v) (or (red? v) (blue? v))) (define (red? v) ) (define (blue? v) ) 5 which is different than (define (fish? v) (or (red? v) (blue? v))) (let () (define (red? v) ) (define (blue? v) ) 5) At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf ~v/n (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf ~v\n result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
