Huh, I must have missed this the first time around. I've run into this sort 
of thing multiple times before and it usually brings me to this question:

What if the configuration file was the main module of your app, instead of 
something imported by your app?

Think about it. The "my-project/config/local" and 
"my-project/config/production" modules are essentially saying "to run the 
app locally, set the project config to these values". What module could 
possibly have a use for that information other than the main "app startup" 
module? It seems like all other code should only depend on modules that 
define the *schema *of configuration, rather than any modules that set that 
configuration to specific values. It seems odd for the schema definition 
module (my-project/config) to depend on modules that actually use that 
schema to set config values (my-project/config/local). The reverse sounds 
more sensible.

If you make a module written in `#lang my-project/config` expand to a 
`main` submodule that starts up your app you get some other neat Rackety 
things to show off to your colleagues: not only will they get an IDE with 
syntax highlighting and good error messages "for free",  pressing the Run 
button with a config file open will launch the app automatically! This 
might not work if launching your app is especially complicated, but I'm 
curious if you've explored this direction and what your thoughts are.

On Tuesday, November 28, 2017 at 1:28:06 PM UTC-8, Philip McGrath wrote:
> For the benefit of posterity, while I haven't actually solved the 
> cycle-in-loading error, I was able to get the results that I wanted in this 
> case by:
>    1. Implementing the language as a `module` (not `module*` or 
>    `module+`) submodule of "my-project/config.rkt", including a
>    (module reader syntax/module-reader
>      #:language '(submod my-project/config lang))
>    2. In the body of the outer `my-project/config` module, instead of 
>    requiring the values from "my-project/config/local.rkt" etc. as usual, 
>    getting them lazily/dynamically, which I am doing with a little wrapper on 
>    top of `define-runtime-module-path-index`, though `racket/lazy-require` 
>    would probably also work well.
> Evaluating the configuration files lazily was particularly good for me 
> because it lets me write, say, "production.rkt" assuming that various 
> things from the production server exist and just raising an error if not, 
> rather than having to make everything in every configuration file run on 
> every machine.
> -Philip

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

Reply via email to