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.

Reply via email to