|
|
|
|
|
# Exports: `provide`
|
|
|
|
|
|
|
|
|
|
|
|
By default, all of a module’s definitions are private to the module. The
|
|
|
|
|
|
`provide` form specifies definitions to be made available where the
|
|
|
|
|
|
module is `require`d.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(provide provide-spec ...)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
A `provide` form can only appear at module level \(i.e., in the
|
|
|
|
|
|
immediate body of a `module`\). Specifying multiple `provide-spec`s in
|
|
|
|
|
|
a single `provide` is exactly the same as using multiple `provide`s each
|
|
|
|
|
|
with a single `provide-spec`.
|
|
|
|
|
|
|
|
|
|
|
|
Each identifier can be exported at most once from a module across all
|
|
|
|
|
|
`provide`s within the module. More precisely, the external name for each
|
|
|
|
|
|
export must be distinct; the same internal binding can be exported
|
|
|
|
|
|
multiple times with different external names.
|
|
|
|
|
|
|
|
|
|
|
|
The allowed shape of a `provide-spec` is defined recursively:
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
identifier
|
|
|
|
|
|
```
|
|
|
|
|
|
In its simplest form, a `provide-spec` indicates a binding within its
|
|
|
|
|
|
module to be exported. The binding can be from either a local
|
|
|
|
|
|
definition, or from an import.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(rename-out [orig-id export-id] ...)
|
|
|
|
|
|
```
|
|
|
|
|
|
A `rename-out` form is similar to just specifying an identifier, but the
|
|
|
|
|
|
exported binding `orig-id` is given a different name, `export-id`, to
|
|
|
|
|
|
importing modules.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(struct-out struct-id)
|
|
|
|
|
|
```
|
|
|
|
|
|
A `struct-out` form exports the bindings created by `(struct struct-id
|
|
|
|
|
|
....)`.
|
|
|
|
|
|
> +See \[missing\] for information on `define-struct`.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(all-defined-out)
|
|
|
|
|
|
```
|
|
|
|
|
|
The `all-defined-out` shorthand exports all bindings that are defined
|
|
|
|
|
|
within the exporting module \(as opposed to imported\).
|
|
|
|
|
|
Use of the `all-defined-out` shorthand is generally discouraged, because
|
|
|
|
|
|
it makes less clear the actual exports for a module, and because Racket
|
|
|
|
|
|
programmers get into the habit of thinking that definitions can be added
|
|
|
|
|
|
freely to a module without affecting its public interface \(which is not
|
|
|
|
|
|
the case when `all-defined-out` is used\).
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(all-from-out module-path)
|
|
|
|
|
|
```
|
|
|
|
|
|
The `all-from-out` shorthand exports all bindings in the module that
|
|
|
|
|
|
were imported using a `require-spec` that is based on `module-path`.
|
|
|
|
|
|
Although different `module-path`s could refer to the same file-based
|
|
|
|
|
|
module, re-exporting with `all-from-out` is based specifically on the
|
|
|
|
|
|
`module-path` reference, and not the module that is actually referenced.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(except-out provide-spec id ...)
|
|
|
|
|
|
```
|
|
|
|
|
|
Like `provide-spec`, but omitting the export of each `id`, where `id` is
|
|
|
|
|
|
the external name of the binding to omit.
|
|
|
|
|
|
|
|
|
|
|
|
```racket
|
|
|
|
|
|
(prefix-out prefix-id provide-spec)
|
|
|
|
|
|
```
|
|
|
|
|
|
Like `provide-spec`, but adding `prefix-id` to the beginning of the
|
|
|
|
|
|
external name for each exported binding.
|
