7.2 Invoking Units

► |  | 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

▼ | 7 | Units

7.1 | Creating Units
7.2 | Invoking Units
7.3 | Linking Units and Creating Compound Units
7.4 | Inferred Linking
7.5 | Generating A Unit from Context
7.6 | Structural Matching
7.7 | Extending the Syntax of Signatures
7.8 | Unit Utilities
7.9 | Unit Contracts
7.10 | Single-Unit Modules
7.11 | Single-Signature Modules
7.12 | Transformer Helpers

On this page:

invoke-unit
define-values/ invoke-unit

top contents ← prev up next →

#### 7.2`` Invoking Units🔗ℹ

> syntax (invoke-unit unit-expr)
> (invoke-unit unit-expr (import tagged-sig-spec ...))

Invokes the unit produced by unit-expr. For each of the unit’s imports, the invoke-unit expression must contain a tagged-sig-spec in the import clause; see unit for the grammar of tagged-sig-spec. If the unit has no imports, the import clause can be omitted.

When no tagged-sig-specs are provided, unit-expr must produce a unit that expects no imports. To invoke the unit, all bindings are first initialized to the #<undefined> value. Next, the unit’s body definitions and expressions are evaluated in order; in the case of a definition, evaluation sets the value of the corresponding variable(s). Finally, the result of the last expression in the unit is the result of the invoke-unit expression.

Each supplied tagged-sig-spec takes bindings from the surrounding context and turns them into imports for the invoked unit. The unit need not declare an import for every provided tagged-sig-spec, but one tagged-sig-spec must be provided for each declared import of the unit. For each variable identifier in each provided tagged-sig-spec, the value of the identifier’s binding in the surrounding context is used for the corresponding import in the invoked unit.

> > syntax
> > (define-values/invoke-unit unit-expr
> > (import tagged-sig-spec ...)
> > (export tagged-sig-spec ...)
> > maybe-results-clause)
> maybe-results-clause |  | = |  |
> |  | | |  | (values result-id ...)
> |  | | |  | (values result-id ... . rest-results-id)

Like invoke-unit, but the values of the unit’s exports are copied to new bindings.

The unit produced by unit-expr is linked and invoked as for invoke-unit. In addition, the export clause is treated as a kind of import into the local definition context. That is, for every binding that would be available in a unit that used the export clause’s tagged-sig-spec as an import, a definition is generated for the context of the define-values/invoke-unit form.

If no maybe-results-clause is provided, the unit body may return any number of values, all of which are ignored. Otherwise, the values returned from the unit body are bound to the given result-ids, in order. If no rest-results-id is provided, the body must return exactly as many values as there are result-ids, but if it is provided, the body may return arbitrarily many more, and rest-results-id is bound to a list containing the extra results.

Changed in version 8.8.0.7 of package base: Added maybe-results-clause.

top contents ← prev up next →