Hi Eric! Thanks very much for the reply. Eric Griffis writes:
>> It appears there must be; when I look at `build-program` in >> sandbox.rkt it also looks like it's wrapping things in a module >> structure... but I don't see how it then exports from that module or >> how the code evaluating it imports its export. Or does it actually >> do so via an effect? I see there are some channels involved >> (input-ch / result-ch) so maybe it's passing back the result through >> there, but I am having trouble figuring out how. > > Apologies for stating the obvious, but to get a value out of a module, we > `provide` it: > > In foo/main.rkt: > > ``` > (define-syntax-rule (foo-module-begin form ... final-form) > (#%module-begin (provide the-foo) form ... (define the-foo final-form))) > ``` > > Then we can produce and consume foo-based modules like this: > > ``` > (module bar-mod foo (define bar 1) (+ bar 2)) > > (define my-bar (let () (local-require 'bar-mod) the-foo)) > ``` This approach works, but I'm not sure it works for my use case, because `module` is appearing at compile-time. Let me try to lay out the use case, and maybe it helps. - We are in a MUD, or some other interactive game. The game is running live. Some players have capabilities to provide new code for game characters in the system or other interesting features. - The users are able to write scripts that return things... however, they are providing the scripts as the game is running. (This will be ocap safe, but I'll explains how that works in a separate email... just trust me that I believe that if I can run it with in a special restricted language and return a value from that module which is loaded *at runtime* somehow, I can pull off this goal safely.) As such, we cannot at the time that we are starting the program actually know or load all of the modules, because the users are providing some of them live. - As such we need to be able to do something along the lines of what you just did, but we have to do it at runtime. - I don't necessarily want to attach each of these user-supplied modules to a global namespace; a user might experiment with making many of them, and there's no need. Does that make sense? I'll explain more about how this can be ocap safe in a future email. For the moment, if you're curious on how this design works, more is here (the "emaker" pattern): http://www.skyhunter.com/marcs/ewalnut.html#SEC16 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87tv7bh4cp.fsf%40dustycloud.org.
