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

Reply via email to