> > I wonder whether a submodule is a better approach here. DrRacket > implicitly runs a `test` submodule, while `racket` doesn't, and you > could add more submodules to the list in DrRacket. But that approach > doesn't work if the conditional adjustment goes in a library, instead > of the main module. >
The library could provide a language that added the needed submodules automatically, much like how `configure-runtime` submodules are currently added. What about an `interaction` submodule that worked sort of like `main`, but was run when a program is both run as the main program *and *run in an environment where the user expects to interact with the live running program in some way? The default `#%module-begin` of `racket/base` could add an `interaction` submodule that implements the normal racket REPL, while a domain specific language for configuring a server (think of something like #lang htaccess) could provide a "REPL" that lets you "do stuff" to the server, like restart it, reload config, etc. My thinking is that the important distinction is not about whether a program is running in a dev environment or a prod environment - it's about whether the programmer wishes to *interact* with the program after running it. How to interact with the running program should be defined by the program itself, not tools on top of the program. Tools should only allow a programmer to declare their intent to interact. -- 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.
