A rule of thumb you can follow to avoid tricky bugs like this: *never use
string literals as dynamic module names.* Anywhere you see a dynamic /
reflective function on modules called with a literal string, a
contradiction exists between the programmer and the dynamic function:
1. The programmer intends to use a specific module referenced in the
context of the program source code.
2. The dynamic function intends to operate on an arbitrary unknown module
referenced in the context of the program execution environment.
This is why define-runtime-path exists. It acts as a bridge between the two
worlds of the module system used to compile a program source and the module
system that compiled program interacts with at runtime. The two systems
cannot be assumed identical because 1) a program may be compiled on one
machine and executed on another and 2) modules only used at compilation
time may be excluded from the compiled form of a program.
The "place-worker.rkt" example in the places docs is somewhat misleading
since it refers to the place-launching code as if it wasn't in a module
(note that no file names are mentioned in the example other than
"place-worker.rkt"). It would be clearer if it named the launcher code
"place-launcher.rkt", clarified that "place-launcher.rkt" and
"place-worker.rkt" must be in the same directory, and used
(define-runtime-path worker-mod "place-worker.rkt") to refer to the worker
module from the launcher module.
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
For more options, visit https://groups.google.com/d/optout.