► |  | Reference: PLT Scheme

1 | Language Model
2 | Syntactic Forms
3 | Datatypes
4 | Structures
5 | Classes and Objects
6 | Units
7 | Contracts
8 | Pattern Matching
9 | Control Flow
10 | Concurrency
11 | Macros
12 | Input and Output
13 | Reflection and Security
14 | Operating System
15 | Memory Management
16 | Unsafe Operations
17 | Running PLT Scheme
| Bibliography
| Index

▼ | 13 | Reflection and Security

13.1 | Namespaces
13.2 | Evaluation and Compilation
13.3 | The scheme/ load Language
13.4 | Module Names and Loading
13.5 | Security Guards
13.6 | Custodians
13.7 | Thread Groups
13.8 | Structure Inspectors
13.9 | Code Inspectors
13.10 | Sandboxed Evaluation

On this page:

current-code-inspector

top← prev up next →

#### 13.9`` Code Inspectors

In the same way that inspectors control access to structure fields (see Structure Inspectors), inspectors also control access to module bindings. The default inspector for module bindings is determined by the current-code-inspector parameter, instead of the current-inspector parameter.

When a module declaration is evaluated, the value of the current-code-inspector parameter is associated with the module declaration. When the module is invoked via require or dynamic-require, a sub-inspector of the module’s declaration-time inspector is created, and this sub-inspector is associated with the module invocation. Any inspector that controls the sub-inspector (i.e., the declaration-time inspector and its superior) controls the module invocation.

Control over a module invocation enables

- the use of module->namespace on the module;

- access to the module’s protected identifiers, i.e. those identifiers exported from the module with protect; and

- access to the module’s protected and unexported variables within compiled code from read (see current-compile).

If the value of current-code-inspector never changes, then no control is lost for any module invocation, since the module’s invocation is associated with a sub-inspector of current-code-inspector.

The inspector for a module invocation is specific to a particular module registry, in case a module is attached to a new registry via namespace-attach-module. The invocation inspector in a particular registry can be changed via namespace-unprotect-module (but changing the inspector requires control over the old one).

Control over a module declaration (as opposed to a mere invocation) enables the reconstruction of syntax objects that contain references to the module’s unexported identifiers. Otherwise, the compiler and macro expander prevent any reference to an unexported identifier, unless the reference appears within an expression that was generated by the module’s macros (or, more precisely, a macro from a module whose declaration inspector controls the invocation of the identifier’s module). See Syntax Certificates for further information.

(current-code-inspector) → inspector?
(current-code-inspector insp) → void?
insp : inspector?

A parameter that determines an inspector to control access to module bindings and redefinitions.
top← prev up next →