3.3 Import🔗ℹ

The import_clause variant import_item or import_item: modifier; ... are the canonical forms. The other import_clause forms are converted into a canonical form:

• import_item modifier is the same as import_item: modifier, where modifier might include a block argument. This form is handy when only one modifier is needed.

• import_item modifier: modifier; ... is the same as import_item: modifier; modifier; ... where the initial modifier does not accept a block argument. This form is especially handy when the initial modifier is open or as id and additional modifiers are needed.

• modifier: import_clause; ... is the same as the sequence of import_clauses with modifier add to the end of each import_clause. This form is especially handy when modifier is meta.

An import_item is typically a module_path, but it can be a juxtaposed combination of parsed module_paths, or it can be another import clause form defined with impo.macro.

By default, each clause with a module_path binds a prefix name that is derived from the module_path’s last element. Imports from the module are then accessed using the prefix, ., and the provided-provided name. The as modifier with an identifier supplies a prefix to use, instead, while the as modifier with ~none indicates that only exposed names should be bound.

A module_path clause can be be adjusted through one or more modifiers. The set of modifiers is extensible, but includes as, rename, and expose.

A module_path references a module in one of several possible forms:

• collection_module_path: refers to an installed collection library, where the / operator acts as a path separator. Each id in the path is constrained to contain only characters allowed in a string module path, with the additional constraint that . is disallowed. A module path of this form refers to a file with the ".rhm" suffix.

• string: refers to a module using string as a relative path. The string can contain only the characters a-z, A-Z, 0-9, -, +, _, /, ., and %. Furthermore, a % is allowed only when followed by two lowercase hexadecimal digits, and the digits must form a number that is not the ASCII value of a letter, digit, -, +, or _.

• lib(string): refers to an installed collection library, where string is the library name. The same constraints apply to string as when string is used as a relative path by itself, with additional constraints: at least one / is required, and . and .. directory indicators are disallowed. When string does not end with a file suffix, ".rhm" is added.

• file(string): refers to a file through a platform-specific path with no constraints on string.

• module_path ! id: refers to submodule of another module. The submodule name id is used as the default import prefix.

• .id: refers to a namespace id, which might be predefined like List, or might be bound by namespace or as a prefix with import.

• module_path.id: a shorthand for importing only id from module_path path and then importing with .id. The last id in a dotted sequence is allowed to be an export that is not a namespace, in which case the dotted form is a shorthand for exposing just id from module_path. This form can be modified by meta, meta_label, only_meta, or only_meta_label only when a single dot is used and module_path does not refer to a namespace.

• module_path.(op): the same shorthand, but for operators.

• self: refers to the enclosing module itself, usually combined with ! to refer to a submodule of the enclosing module.

• parent: refers to the parent of the enclosing submodule, sometimes combined with ! to refer to a sibling submodule or with additional !s to reach an ancestor of the enclosing submodule.

In an interactive context, such as a read-eval-print loop (REPL), self!id refers to a module declared interactively with name id.

The form parent refers to the parent of an enclosing submodule. A parent form may be followed by !id to access a submodule of the enclosing module (i.e., a sibling submodule). When additional additional ! operators are used before an id or without a subsequent id, each ! refers to an enclosing parent, thus reaching an ancestor module.

See import for more information.

If ~scope_like id is specified, then the name part of id does not matter, but its scopes are used for the exposed bindings. Otherwise, the scopes for each exposed binding is derived from the module or namespace specification that this open form modifies.

If as is used, the id is renamed in addition to being exposed, or in other words, it behaves like a combination of rename and expose.

This modifier is valid only for module paths that refer to modules, as opposed to namespace bindings, and it is not currently supported for module paths that use the . operator.

This modifier is valid only for module files that refer to modules, as opposed to namespace bindings, and it is not currently supported for module paths that use the . operator

This modifier is valid only for module paths that refer to modules, as opposed to namespace bindings, and it is not currently supported for module paths that use the . operator unless phase is 0.

The #%juxtapose form is implicitly used when an import is used after another import in an import position. See also Implicit Forms.

The format of a module_path or the content of mod_stx is the same as for import, except that . is supported only at the very beginning of a module path in ModulePath.

The ModulePath expression form (which has immediate quotes instead of a parenthesized argument expression) statically checks that module_path is well-formed, while the ModulePath function can check only when it is called. In both cases, however, the generated module path is relative to the top-level environment, not the enclosing context.

The ModulePath.s_exp function produces the Racket form of a Rhombus module path, which is suitable for use with Racket functions that expect a module path.