▼ |  | Unstable: May Change Without Warning

1 | Guidelines for Developing unstable Libraries
2 | Automata: Compiling State Machines
3 | Bytes
4 | Contracts
5 | Converting Values to Strings
6 | Contracts for Macro Subexpressions
7 | Debugging
8 | Definitions
9 | Filesystem
10 | Find
11 | Flonums
12 | Futures
13 | Functions
14 | Hash Tables
15 | Interface-Oriented Programming for Classes
16 | Lazy Require
17 | Lists
18 | Logging
19 | Mark Parameters
20 | Match
21 | Parameter Groups
22 | Pretty-Printing
23 | Sequences
24 | Strings
25 | Structs
26 | Syntax
27 | Temporal Contracts: Explicit Contract Monitors
28 | GUI Libraries

On this page:

lazy-require
begin-on-demand

Version: 5.3
top← prev up next →

### 16`` Lazy Require

Ryan Culpepper <ryanc@racket-lang.org>

This library is unstable; compatibility will not be maintained. See Unstable: May Change Without Warning for more information.

(require unstable/lazy-require)

> > syntax

> > (lazy-require [mod (imported-fun-id ...)] ...)

> mod |  | = |  | module-path
> |  | | |  | ,module-path-expr

> | module-path-expr |  | : |  | module-path?

Defines each imported-fun-id as a function that, when called, dynamically requires the export named 'imported-fun-id from the module specified by mod and calls it with the same arguments.

The module mod can be specified as a module-path (see require) or as an unquote-escaped expression that computes a module path. As with define-runtime-module-path-index, a module-path-expr is evaluated both in phase 0 and phase 1.

> > syntax

> > (begin-on-demand #:export (fun-id ...)
> > body ...+)

Defines each fun-id as a function that, when called, dynamically loads and executes the body forms. The body forms must contain definitions for each fun-id, and the value of each fun-id must be a function.

A body form may be any module-level form except provide. In particular, require forms are allowed.

The body forms are placed within a submodule that extends the scope of the enclosing module (ie, module* with #f in the language position). Consequently, any references to sibling submodules must include a with ".." module path element.

top← prev up next →