7.4 Inferred Linking🔗ℹ
| (define-unit unit-id | | (import tagged-sig-spec ...) | | (export tagged-sig-spec ...) | | init-depends-decl | | unit-body-expr-or-defn | | ...) |
|
Binds unit-id to both a unit and static information about the
unit.
Evaluating a reference to a unit-id bound by
define-unit produces a unit, just like evaluating an
id bound by (define id (unit ...)). In addition,
however, unit-id can be used in compound-unit/infer.
See unit for information on tagged-sig-spec,
init-depends-decl, and unit-body-expr-or-defn.
|
| |
| tagged-infer-link-import | | = | | tagged-sig-id | | | | | | | (link-id : tagged-sig-id) | | | | | | | | tagged-infer-link-export | | = | | (tag id infer-link-export) | | | | | | | infer-link-export | | | | | | | | infer-link-export | | = | | link-id | | | | | | | sig-id | | | | | | | | infer-linkage-decl | | = | | | ((link-binding ...) unit-id | | tagged-link-id ...) |
| | | | | | | unit-id |
|
Like
compound-unit. Syntactically, the difference between
compound-unit and
compound-unit/infer is that the
unit-expr for a linked unit is replaced with a
unit-id, where a
unit-id is bound by
define-unit (or one of the other unit-binding forms that we
introduce later in this section). Furthermore, an import can name just
a
sig-id without locally binding a
link-id, and an
export can be based on a
sig-id instead of a
link-id, and a declaration in the
link clause can be
simply a
unit-id with no specified exports or imports.
The compound-unit/infer form expands to
compound-unit by adding sig-ids as needed to
the import clause, by replacing sig-ids in the
export clause by link-ids, and by completing
the declarations of the link clause. This completion is based
on static information associated with each
unit-id. Links and exports can be inferred when all
signatures exported by the linked units are distinct from each other
and from all imported signatures, and when all imported signatures are
distinct. Two signatures are distinct only if they
share no ancestor through extends.
The long form of a link declaration can be used to resolve
ambiguity by giving names to some of a unit’s exports and supplying
specific bindings for some of a unit’s imports. The long form need not
name all of a unit’s exports or supply all of a unit’s imports if the
remaining parts can be inferred.
When a unit declares initialization dependencies,
compound-unit/infer checks that the link declaration
is consistent with those dependencies, and it reports a syntax error if
not.
Like compound-unit, the compound-unit/infer form
produces a (compound) unit without statically binding information
about the result unit’s imports and exports. That is,
compound-unit/infer consumes static information, but it does
not generate it. Two additional forms,
define-compound-unit and
define-compound-unit/infer, generate static information
(where the former does not consume static information).
Changed in version 6.1.1.8 of package base: Added static checking of the link
clause with respect to declared
initialization dependencies.
Like
compound-unit, but binds static information about the
compound unit like
define-unit, including the propagation of
initialization-dependency information (on remaining imports) from the
linked units.
Like
define-unit, but the unit implementation is determined
from an existing unit produced by
unit-expr. The imports and
exports of the unit produced by
unit-expr must be consistent
with the declared imports and exports, otherwise the
exn:fail:contract exception is raised when the
define-unit-binding
form is evaluated.
Like
invoke-unit, but uses static information associated with
unit-id to infer which imports must be assembled from the
current context. If given a link form containing multiple
link-unit-ids, then the units are first linked via
define-compound-unit/infer.
When assembling imports from the current context, the lexical
information of a unit-id is used for constructing the lexical
information of the signatures for the unit’s imports (i.e., the lexical
information that would normally be derived from the signature reference).
See define-signature for more information.
|
|
| |
| unit-spec | | = | | unit-id | | | | | | | (link link-unit-id ...) | | | | | | | | maybe-exports | | = | | | | | | | | | (export tagged-sig-spec ...) | | | | | | | | maybe-results-clause | | = | | | | | | | | | (values result-id ...) | | | | | | | (values result-id ... . rest-results-id) |
|
Like
define-values/invoke-unit, but uses static information
associated with
unit-id to infer which imports must be
assembled from the current context and, if no
export clause
is present, which exports should be bound by the definition. If given
a link form containing multiple
link-unit-ids, then the units
are first linked via
define-compound-unit/infer.
Similar to invoke-unit/infer, the lexical information
of a unit-id is used for constructing the lexical information
of the signatures for the unit’s inferred imports and inferred exports
(i.e., the lexical information that would normally be derived from a
signature reference). See define-signature for more
information.
If maybe-results-clause is provided, the values returned by
the unit body are bound in the same way as define-values/invoke-unit.
For backwards compatibility, an export clause is allowed to
appear before unit-spec (in which case no maybe-results-clause
may be provided). New programs should provide unit-spec first
(which is consistent with define-values/invoke-unit).
Changed in version 8.8.0.7 of package base: Allowed unit-spec to appear before
maybe-exports for consistency with define-values/invoke-unit
and added maybe-results-clause.