I am sorry, I've not explained well my intents. My actual situation is like this: I have a main.rkt file which require the most of all other modules, and it is the entry point of the application, it provide access to almost all procedures contained in the required modules. Modules are abundant in number and any one need to require procedures from tens of other modules. It is an intricate web of relations, fairly hard to maintain and reason about, in effect.
What I was asking is if will be acceptable and/or advisable to have another type of approach: Having a main.rkt which use (include path-spec) from racket/include to inline code from what was before a collection of modules, and now simply a collection of source files containing a bunch of functions, "loaded" in a specific order, without providing or requiring anything explicitly, because all will be finally accumulated in the sole namespace of main.rkt. It will be possible even to make a script which will "compile" this set of files in a single "program.rkt" of one million of line of code (joking). If not for the ugliness of this, it can be done easily. But I am not sure this is the way to go, feels like an hack... I need some confirms it is not a big no no. On Thursday, May 28, 2015 at 6:53:19 PM UTC+2, Michael Tiedtke wrote: > Include can't really handle mutual require references (if not with a main > file which holds all the excludes) but in general cyclic references were only > a problem for really old garbage collectors, I heard. Perhaps this is why a > lot of people try to avoid interdependencies in memory, in disk and ... > > "This straightforward analysis caught three full days worth of never-executed > branches, transitive require assumptions, spelling errors, undocumented > procedures, missing procedures, and cyclic dependencies in SLIB." > > Perhaps it's still worthwile having a look at the origins of /require/ and > /provide/ when it comes to the Scheme: SLIB > http://people.csail.mit.edu/jaffer/slib/The-Library-System.html > > With the concept of a catalog datastructure one could come up with a solution > based on /include/ or even try to "fiddle" around with the require > definitions with /read/? One could even try to fix Racket's module system. > Instead of outputting the error message that something cyclic was found one > could stop that cycle and simply go on? -- 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.
