GNU Info
(librep.info)Compiler Declarations
Compiler Declarations
---------------------
It is often useful to be able to give the compiler extra knowledge
about the program forms that it is compiling. The language includes
special declaration forms that have no effect when interpreted, but are
meaningful to the compiler as it traverses the program.
- Macro: declare clause...
Offer the information contained in the CLAUSE... forms to the
compiler, which it may or may not use when compiling the program.
Each CLAUSE is a list, the first element of each clause is a
symbol defining the type of declaration, the interpretation of any
other elements in the clause depends upon the declaration type.
The following table lists the syntax of all currently supported
declaration types:
`(bound VARIABLES...)'
This declaration tells the compiler that all symbols VARIABLES
have lexical bindings for the extent of the current lexical
scope. This is often useful to prevent spurious compiler
warnings.
`(special VARIABLES...)'
This tells the compiler that all symbols VARIABLES have
special (dynamic) bindings for the extent of the current
lexical scope.
(It is important that the compiler is able to distinguish
special bindings from lexical bindings, since different
instruction sequences must be generated to access the
different types of binding.)
`(unused VARIABLES...)'
Directs the compiler not to warn about bindings for
VARIABLES... being unreferenced.
`(inline NAMES...)'
Tells the compiler that it should consider inlining calls to
the functions called NAMES.... Inlining will only occur if
these functions are declared in the same module as, and
after, the declaration itself.
`(in-module MODULE-NAME)'
This declaration should occur at the top-level of a program;
it tells the compiler that the forms in the program will be
evaluated within the context of the module called MODULE-NAME
(a symbol).
`(language MODULE)'
Explicitly specifies the particular language dialect that the
current module or file body is written for. Language dialects
included with the librep distribution include `rep', `scheme'
and `unscheme'. These are also the names of the modules that
should be imported to use a particular dialect.
By default, the `rep' dialect is assumed for code outside
module definitions. For code inside a module definition the
list of imported modules is scanned for a known language
dialect (i.e. if the module imports `rep', then the rep
language dialect is compiled for).
`(unsafe-for-call/cc)'
Tell the compiler that it may register-allocate variables,
even if it can't prove that doing so wouldn't produce
incorrect results if `call/cc' causes a function call to
return more than once (Note: Continuations). This
declaration applies to the entire file that it occurs in.
Without this declaration, the compiler will only
register-allocate bindings if the following conditions are
met:
* the binding is not accessed from any inner closures, and,
* the binding is never modified after being initialized
(actually, the binding may be modified between being
intialized and the next function call)
this declaration is often useful where `call/cc' isn't used,
and there is a lot of side effecting of local variables.
Declaration forms always evaluate to false.
A second type of declaration is the `eval-when-compile' form, it
allows Lisp forms to be evaluated only at compile-time.
- Macro: eval-when-compile form
This form tells the system that FORM should only be evaluated when
the containing code is being compiled.
The compiler knows to recognize FORMs of the pattern
`(eval-when-compile (require 'FEATURE))' as marking that FEATURE
should be imported at compile-time. Any other FORMs are simply
evaluated in an unspecified environment.
When interpreted, `eval-when-compile' forms alway evaluate to
false, when compiled they evaluate to the result of evaluating the
FORM at compile-time.
automatically generated by info2www version 1.2.2.9