If the issue you're facing is mutual dependencies between modules, then using units[1] is one possible solution.
Units are first-class modules that allow cyclic linking, and would avoid the need to use include. In particular using #lang racket/unit [2] may be useful to convert each the modules required by main.rkt into a unit. Then main.rkt would probably link the required modules together and invoke the result. Dan [1]: http://docs.racket-lang.org/guide/units.html [2]: http://docs.racket-lang.org/guide/Whole-module_Signatures_and_Units.html ----- Original Message ----- From: "Lux" <glsdes...@gmail.com> To: racket-users@googlegroups.com Cc: "michael tiedtke" <michael.tied...@o2online.de> Sent: Thursday, May 28, 2015 2:48:46 PM Subject: Re: [racket-users] Dozens and dozens of interdependent modules, better to use include? 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. -- 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.
