All program code is contained in a module, through the use of module or one of its variants. A module expression includes a name, an , and a body containing other expressions:
For instance, this code creates a module named my-module, using the br expander, with one expression inside (in an exception to the usual custom, run these samples in DrRacket without a #lang br line at the top, or on the REPL):
The expander supplies the initial that are available to expressions inside the module. If those expressions refer to bindings not provided by the expander, or not otherwise imported within the module (with require), then the module will not run.
For instance, this module will work, because format-datum is provided by the br language:
But this module will not, because format-datum is not provided by the racket language:
But that can be fixed with a require, and this version will run:
Modules are “lazy” in the sense that the code inside a module never runs until that module is explicitly requested (say, by a require from elsewhere—see importing and exporting).
“What about a source file with a #lang line?” The #lang line is just a disguised module expression. Every source file with a #lang line expands to a single module expression at the top level. For instance, these two programs are the same, and will both print 42:
#lang br (* 6 7)
This is why in Racket lingo, a source file is also called a module.
“What about expressions entered at a REPL?” These expressions are treated as if they belong to the top-level module of the language being used.
Modules can be nested inside each other to create hierarchies of submodules. They can be nested to any depth, but typically go down only one level. Submodules are defined with the same module syntax as regular modules. Submodules have two additional rules:
A submodule can require its enclosing module, or vice versa, but not both.
Contrary to Racket’s usual evaluation rules, a submodule does not automatically run when its enclosing module runs; likewise, running a submodule does not automatically run its enclosing module.
This last rule is important, and nicely magical: even when modules are nested, they behave like totally independent programs. In the example below, the awake submodule has an enclosing tired module and a also-tired submodule that will take a long time to run. But with a (require (submod ...)) expression, you can run the awake submodule without triggering the others:
1 2 3 4 5 6 7 8 9 10 11
submod allows access to submodules through a pathlike notation. In this case, "." means “start in the current module,” and tired awake is the submodule “path.”
module+ defines a module that adopts all the bindings of the surrounding module. It can still define and provide additional bindings. It can also be defined in separate pieces: all module+ expressions with the same name will be combined into a single submodule.
module* defines a module that can require its enclosing module (but not vice versa).
Any code in a main submodule will be evaluated when the enclosing source file is run directly in DrRacket or on the command line, but not when it the source file is required. This allows a source file to provide bindings but also have different behavior when it’s invoked directly:
It’s common in Racket to put inside a submodule called test (usually declared with module+, so it can use all the variables defined nearby). See unit testing.
When a language is specified on the #lang line, Racket will first try invoke the reader for that language. The first place Racket looks for a reader is in a reader submodule of the source file indicated.
#lang "yo.rkt" ; looks for reader in `(submod "yo.rkt" reader)` #lang br ; looks for reader in `(submod br reader)`