Re: [racket-dev] require sub-forms
Actually, I grepped through the source in the hope that that's precisely what I would find. It's when I didn't that I wrote the list. Shriram On Wed, Aug 25, 2010 at 10:11 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Tue, Aug 24, 2010 at 10:18 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 24, Jay McCarthy wrote: There is not now but we could make a module that only exported them so you could provide all-from-out it and thus centralize the list of subforms. That's the cleanest idea I have. This assumes you want only the core ones, and not things that are defined in other libraries (like in `racket/require'). (You don't want to hear my really bad ideas) (#rx-in$ ?) That's not my bad idea, which might not be so bad actually. I'm imagine a new require/provide transformer that names sets of exports: in require/provide.rkt : (define-export-set require-sub-forms only-in except-in ...) (define-export-set provide-sub-forms all-defined-out all-from-out ...) ; These expand to static information (define-provide-syntax (all-from-export-set-out stx) ; looks at the syntax-local-value of stx and pulls out the identifiers from the definition above ; and expands to (combine-out id ...) ...) ... in sk.rkt: (provide (all-from-export-set-out require-sub-forms) (all-from-export-set-out provide-sub-forms)) Jay -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] require sub-forms
On Wed, Aug 25, 2010 at 8:18 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 25, Jay McCarthy wrote: On Tue, Aug 24, 2010 at 10:18 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 24, Jay McCarthy wrote: There is not now but we could make a module that only exported them so you could provide all-from-out it and thus centralize the list of subforms. That's the cleanest idea I have. This assumes you want only the core ones, and not things that are defined in other libraries (like in `racket/require'). (You don't want to hear my really bad ideas) (#rx-in$ ?) That's not my bad idea, which might not be so bad actually. I'm imagine a new require/provide transformer that names sets of exports: in require/provide.rkt : (define-export-set require-sub-forms only-in except-in ...) (define-export-set provide-sub-forms all-defined-out all-from-out ...) ; These expand to static information [...] But it won't be a solution to the problem, because these definitions would appear in a place that is not where they were made -- so when a new form is added to the core language, someone needs to remember to update these export sets wherever they're defined. So it looks much better to me to put the sets where the forms are defined -- but that's practically the same as your earlier suggestion to organize the code so that the bindings all conveniently come from a single module. (My other guess was something like `filtered-out' that checks the bindings and filters only those that have a value that is the right kind of transformer -- but I'm not sure that this can work.) I agree that it's basically the same when done right, which is why I initially suggested the simpler solution. I think the one benefit of these export sets is that they make it a language abstraction rather than a convention of where to put files. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] require sub-forms
On Aug 25, Jay McCarthy wrote: I agree that it's basically the same when done right, which is why I initially suggested the simpler solution. I think the one benefit of these export sets is that they make it a language abstraction rather than a convention of where to put files. IMO, the high level problem is where to put these things. But thinking about it more, these sets seem completely equivalent to adding some racket/bindings-sets/require-provide.rkt file with #lang racket/base (provide require provide blah-in blah-out ...) which can now be used just the same, and more files could encapsulate other sets. (It still suffers from the above problem though, so I don't think it should actually be done. Maybe if there was a way to automatically test that these files are in sync with the sets they're supposed to provide.) -- ((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
Re: [racket-dev] require sub-forms
There is not now but we could make a module that only exported them so you could provide all-from-out it and thus centralize the list of subforms. That's the cleanest idea I have. (You don't want to hear my really bad ideas) Jay Sent from my iPhone On Aug 24, 2010, at 8:46 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Is there a way to say give me all the require sub-forms instead of having to enumerate them explicitly: (provide require only-in except-in prefix-in rename-in combine-in only-meta-in for-syntax for-template for-label for-meta) thereby missing some in future extensions of the base language? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
