> 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
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
For more options, visit https://groups.google.com/d/optout.