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 to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
