July 1st Wednesday (七月 一日 水曜日)

Namespace in mzscheme

  For expansion purposes, a namespace maps each symbol in each phase level to one of three possible bindings:

*a particular module binding from a particular module

*a top-level transformer binding named by the symbol

*a top-level variable named by the symbol

  A namespace is purely a top-level entity, not to be confused with an environment. In particular, a namespace does not encapsulate
the full environment of an expression inside local-binding forms.

  If an identifier is bound to syntax or to an import, then defining the identifier as a variable shadows the syntax or import in
future uses of the environment. Similarly, if an identifier is bound to a top-level variable, then binding the identifier to syntax
or an import shadows the variable; the variable's value remains unchanged, however, and may be accessible through previously evaluated
expressions.

  After a namespace is created, module instances from existing namespaces can be attached to the new namespace. In terms of the evaluation
model, top-level variables from different namespaces essentially correspond to definitions with different prefixes. Furthermore, the first
step in evaluating any compiled expression is to link its top-level variable and module-level variable references to specific variables in
the namespace.

  At all times during evaluation, some namespace is designated as the current namespace. The current namespace has no particular relationship,
however, with the namespace that was used to expand the code that is executing, or with the namespace that was used to link the compiled form
of the currently evaluating code. In particular, changing the current namespace during evaluation does not change the variables to which executing
expressions refer. The current namespace only determines the behavior of reflective operations to expand code and to start evaluating expanded/compiled
code.