Similar to scheme/include, but with a different syntax
for paths.
| (include path-spec) |
| |
| path-spec | | = | | string | | | | | | | (build-path elem ...+) | | | | | | | (lib file-string collection-string ...) | | | | | | | | elem | | = | | string | | | | | | | up | | | | | | | same |
|
Inlines the syntax in the designated file in place of the
include expression. The
path-spec can be any of the
following:
A literal string that specifies a path to include, parsed
according to the platform’s conventions (which means that it is
not portable).
A path construction of the form (build-path elem ...+), where build-path is
module-identifier=? either to the build-path
export from mzscheme or to the top-level
build-path, and where each elem is a path
string, up (unquoted), or same (unquoted).
The elems are combined in the same way as for the
build-path function to obtain the path to include.
A path construction of the form (lib file-string collection-string ...), where lib is free or refers
to a top-level lib variable. The
collection-strings are passed to
collection-path to obtain a directory; if no
collection-stringss are supplied, "mzlib" is
used. The file-string is then appended to the
directory using build-path to obtain the path to
include.
If path-spec specifies a relative path to include, 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 the current load relative directory if one is available,
or to the current directory otherwise.
The included syntax is given the lexical context of the
include expression.