From ea0958e3625b6f24e7c6bbd8a18aa760023a619d Mon Sep 17 00:00:00 2001 From: Matthew Flatt Date: Wed, 21 Jan 2009 15:44:30 +0000 Subject: [PATCH] doc clarifications on module constants svn: r13248 --- collects/scribblings/guide/module-set.scrbl | 15 ++++++++++----- collects/scribblings/reference/syntax.scrbl | 11 +++++++++-- 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/collects/scribblings/guide/module-set.scrbl b/collects/scribblings/guide/module-set.scrbl index c81b0139a2..07f0de5b14 100644 --- a/collects/scribblings/guide/module-set.scrbl +++ b/collects/scribblings/guide/module-set.scrbl @@ -45,14 +45,19 @@ binding. For essentially the same reason that it helps programmers, the prohibition on assignment to imports also allows many programs to be executed more efficiently. -Along the same lines, re-declaration of a module is not generally -allowed. Indeed, for file-based modules, simply changing the file does -not lead to a re-declaration, because file-based modules are loaded on +Along the same lines, when a module contains no @scheme[set!] of a +particular identifier that is defined within the module, then the +identifier is considered a @defterm{constant} that cannot be +changed---not even by re-declaring the module. + +Consequently, re-declaration of a module is not generally allowed. +For file-based modules, simply changing the file does not lead to a +re-declaration in any case, because file-based modules are loaded on demand, and the previously loaded declarations satisfy future requests. It is possible to use Scheme's reflection support to re-declare a module, however, and non-file modules can be re-declared -in the @tech{REPL}; in such cases, the redeclaration may fail if it -involves the re-definition of a previously immutable binding. +in the @tech{REPL}; in such cases, the re-declaration may fail if it +involves the re-definition of a previously constant binding. @interaction[ (module m scheme diff --git a/collects/scribblings/reference/syntax.scrbl b/collects/scribblings/reference/syntax.scrbl index 59b70b3eaa..b1c1eb1ffd 100644 --- a/collects/scribblings/reference/syntax.scrbl +++ b/collects/scribblings/reference/syntax.scrbl @@ -164,7 +164,7 @@ defined. No expression can refer to a @tech{top-level variable}. The evaluation of a @scheme[module] form does not evaluate the expressions in the body of the module. Evaluation merely declares a module, whose full name depends both on @scheme[id] and -@scheme[(current-module-name-prefix)]. +@scheme[(current-module-declare-name)]. The module body is executed only when the module is explicitly @techlink{instantiate}d via @scheme[require] or @@ -173,7 +173,12 @@ are evaluated in order as they appear within the module; accessing a @tech{module-level variable} before it is defined signals a run-time error, just like accessing an undefined global variable. -See also @secref["module-eval-model"] and @secref["mod-parse"]. +If a module (in its fully expanded form) does not contain a +@scheme[set!] for an identifier that defined within the module, then +the identifier is a @defterm{constant} after it is defined; its value +cannot be changed afterward, not even through reflective +mechanisms. The @scheme[compile-enforce-module-constants] parameter, +however, can be used to disable enforcement of constants. When a @tech{syntax object} representing a @scheme[module] form has a @indexed-scheme['module-language] @tech{syntax property} attached, and @@ -186,6 +191,8 @@ be preserved in marshaled bytecode. See also @scheme[module-compiled-language-info] and @scheme[module->language-info].} +See also @secref["module-eval-model"] and @secref["mod-parse"]. + @defform[(#%module-begin form ...)]{ Legal only in a @tech{module begin context}, and handled by the