► |  | The Racket Reference

1 | Language Model
2 | Notation for Documentation
3 | Syntactic Forms
4 | Datatypes
5 | Structures
6 | Classes and Objects
7 | Units
8 | Contracts
9 | Pattern Matching
10 | Control Flow
11 | Concurrency and Parallelism
12 | Macros
13 | Input and Output
14 | Reflection and Security
15 | Operating System
16 | Memory Management
17 | Unsafe Operations
18 | Running Racket
| Bibliography
| Index

▼ | 12 | Macros

12.1 | Pattern-Based Syntax Matching
12.2 | Syntax Object Content
12.3 | Syntax Object Bindings
12.4 | Syntax Transformers
12.5 | Syntax Parameters
12.6 | Local Binding with Splicing Body
12.7 | Syntax Object Properties
12.8 | Syntax Taints
12.9 | Expanding Top-Level Forms
12.10 | Serializing Syntax
12.11 | File Inclusion
12.12 | Syntax Utilities

On this page:

include
include-at/ relative-to
include/ reader
include-at/ relative-to/ reader

top ← prev up next →

#### 12.11`` File Inclusion

(require racket/include) | package: base

The bindings documented in this section are provided by the racket/include and racket libraries, but not racket/base.

> > syntax

> > (include path-spec)

> path-spec |  | = |  | string
> |  | | |  | (file string)
> |  | | |  | (lib string ...+)

Inlines the syntax in the file designated by path-spec in place of the include expression.

A path-spec resembles a subset of the mod-path forms for require, but it specifies a file whose content need not be a module. That is, string refers to a file using a platform-independent relative path, (file string) refers to a file using platform-specific notation, and (lib string ...) refers to a file within a collection.

If path-spec specifies a relative path, the path is resolved relative to the source for the include expression, if that source is a complete path string. If the source is not a complete path string, then path-spec is resolved relative to (current-load-relative-directory) if it is not #f, or relative to (current-directory) otherwise.

The included syntax is given the lexical context of the include expression, while the included syntax’s source location refers to its actual source.

> > syntax

> > (include-at/relative-to context source path-spec)

Like include, except that the lexical context of context is used for the included syntax, and a relative path-spec is resolved with respect to the source of source. The context and source elements are otherwise discarded by expansion.

> > syntax

> > (include/reader path-spec reader-expr)

Like include, except that the procedure produced by the expression reader-expr is used to read the included file, instead of read-syntax.

The reader-expr is evaluated at expansion time in the transformer environment. Since it serves as a replacement for read-syntax, the expression’s value should be a procedure that consumes two inputs—a string representing the source and an input port—and produces a syntax object or eof. The procedure will be called repeatedly until it produces eof.

The syntax objects returned by the procedure should have source location information, but usually no lexical context; any lexical context in the syntax objects will be ignored.

> > syntax

> > (include-at/relative-to/reader context source path-spec reader-expr)

Combines include-at/relative-to and include/reader.
top ← prev up next →