Vitaly pointed out a place where the wording is not clear and seems contradictory. He suggested alternate language. While I agree that the current language seems contradictory, I don't think his wording is good enough. I'd like help from other WG1 members, et al. improving this language.
Here is the latest message in the conversion:
from Vitaly Magerya on Thu, Feb 23, 2012 at 4:41 AM:
Arthur A. Gleckler wrote:
| Page 24, section 5.2.1: "implementations are permitted to provide | an initial environment in which all possible variables are bound | to locations, most of which contain unspecified values" -- this | seems to contradict section 5.1, page 23, where it says "the initial | (or 'top level') environment is empty except for import". The former statement is included because some implementations forbid assignment to any top-level variable using set!' until define' has been used on that variable, while other implementations allow `set!' without a preceding `define'. The latter statement means that the only variable bound to a specific value in the initial environment is `import'. However, it doesn't preclude all other possible variables being bound to locations whose values haven't yet been specified. | This also does not play along with environment specifiers to eval | and load: for example section 6.2, page 51 says "[null-environment] | contains only the bindings [...]" -- in effect, an implementation | that uses the initial environment where everything is bound must | nonetheless support environments where not everything is bound. Based on my description above, can you suggest better wording?
Instead of "[...] contains only the bindings [...]" in null-environment and scheme-report-environment descriptions (page 51, section 6.1) I propose "contains bindings", without "only". In the description of environment I propose using "implementation-specific (possibly empty)" instead of "empty".
Of the 39 Schemes, Racket, Gauche, MIT, Bigloo, Scheme48/scsh, SISC, SCM, Ypsilon, NexJ, STklos, KSi, SigScheme, Shoe, TinyScheme, Scheme 9, Dream, Scheme 7, Schemik, Elk, UMB throw an error when attempting to set! an undefined variaboe.
Chicken, Kawa, Chibi, Chez, Ikarus/Vicare, Larceny, Mosh, IronScheme, RScheme, BDC, XLisp, VX allow it silently.
Guile, Oaklisp print a warning but allow it.
Rep, Owl Lisp do not support set!.
In Chez Scheme's case, this is not actually accurate. The REPL top-level environment expands DEFINEs into SET! expressions, but in this environment, all variables are implicitly bound. In R6RS Library forms, or any clean environment, such as those produced by MODULE forms with IMPORT-ONLY or inside of program scripts, a SET! to an unbound variable will produce an error.
Yes. I should have said that this is the behavior in the REPL.
Treating as editorial.
I went with allowing set! to bind its variable if it is not already bound, but using "as if" language so that the Chez implementation is conformant.
Moved the problematic paragraph to the REPL section, thus avoiding the conflict.
I think R5RS/R7RS provides too much generality and should be clawed back. The implementations which allow set! on unbound identifiers actually don't make the identifiers contain unspecified values. For example, we don't have implementations whose initial state binds foo to 'foo and bar to 'bar, or anything of the sort. Nor do they come back with #<undef> or silence. Instead, an error is signalled when you attempt to evaluate foo and bar.
What I'd like to do is to drop this language altogether and just say (as we already do) that it's an error to set an undefined identifier. Then we can add a note saying that some implementations extend the standard by automatically defining any undefined identifier before setting it.