This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.
Source for ticket #350
cc
changetime
2012-10-11 23:34:50
component
WG1 - Core
description
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.
So "empty" does not mean "unbound", but "unbound or bound to
unspecified values". Can we change "empty" to "unspecified" if
that's the case?
> | 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".
id
350
keywords
milestone
Final Draft
owner
alexshinn
priority
minor
reporter
aag
resolution
fixed
severity
status
closed
summary
Clarify wording explaining almost-empty environments vs. environments containing unspecified values for all possible variables.
time
2012-02-24 13:23:05
type
enhancement
Changes
Change at time 2012-10-11 23:34:50
author
cowan
field
comment
newvalue
Moved the problematic paragraph to the REPL section, thus avoiding the conflict.
oldvalue
10
raw-time
1349973290678264
ticket
350
time
2012-10-11 23:34:50
Change at time 2012-10-11 23:34:50
author
cowan
field
resolution
newvalue
fixed
oldvalue
raw-time
1349973290678264
ticket
350
time
2012-10-11 23:34:50
Change at time 2012-10-11 23:34:50
author
cowan
field
status
newvalue
closed
oldvalue
decided
raw-time
1349973290678264
ticket
350
time
2012-10-11 23:34:50
Change at time 2012-10-09 00:17:20
author
cowan
field
comment
newvalue
oldvalue
9
raw-time
1349716640380659
ticket
350
time
2012-10-09 00:17:20
Change at time 2012-10-09 00:17:20
author
cowan
field
status
newvalue
decided
oldvalue
reopened
raw-time
1349716640380659
ticket
350
time
2012-10-09 00:17:20
Change at time 2012-10-09 00:15:32
author
cowan
field
comment
newvalue
oldvalue
8
raw-time
1349716532071070
ticket
350
time
2012-10-09 00:15:32
Change at time 2012-10-09 00:15:32
author
cowan
field
resolution
newvalue
oldvalue
fixed
raw-time
1349716532071070
ticket
350
time
2012-10-09 00:15:32
Change at time 2012-10-09 00:15:32
author
cowan
field
status
newvalue
reopened
oldvalue
closed
raw-time
1349716532071070
ticket
350
time
2012-10-09 00:15:32
Change at time 2012-10-07 13:22:11
author
cowan
field
comment
newvalue
oldvalue
7
raw-time
1349590931916665
ticket
350
time
2012-10-07 13:22:11
Change at time 2012-10-07 13:22:11
author
cowan
field
resolution
newvalue
fixed
oldvalue
raw-time
1349590931916665
ticket
350
time
2012-10-07 13:22:11
Change at time 2012-10-07 13:22:11
author
cowan
field
status
newvalue
closed
oldvalue
decided
raw-time
1349590931916665
ticket
350
time
2012-10-07 13:22:11
Change at time 2012-10-07 13:12:46
author
cowan
field
comment
newvalue
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.
oldvalue
6
raw-time
1349590366544995
ticket
350
time
2012-10-07 13:12:46
Change at time 2012-07-11 01:07:55
author
cowan
field
comment
newvalue
Treating as editorial.
oldvalue
5
raw-time
1341943675055366
ticket
350
time
2012-07-11 01:07:55
Change at time 2012-07-11 01:07:55
author
cowan
field
status
newvalue
decided
oldvalue
new
raw-time
1341943675055366
ticket
350
time
2012-07-11 01:07:55
Change at time 2012-03-01 07:10:23
author
cowan
field
comment
newvalue
Yes. I should have said that this is the behavior ''in the REPL''.
oldvalue
4
raw-time
1330557023220189
ticket
350
time
2012-03-01 07:10:23
Change at time 2012-03-01 06:49:08
author
arcfide
field
comment
newvalue
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.
oldvalue
3
raw-time
1330555748459166
ticket
350
time
2012-03-01 06:49:08
Change at time 2012-03-01 06:04:25
author
cowan
field
comment
newvalue
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!`.
oldvalue
2
raw-time
1330553065727454
ticket
350
time
2012-03-01 06:04:25
Change at time 2012-02-24 14:07:20
author
cowan
field
comment
newvalue
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.
oldvalue
1
raw-time
1330063640867834
ticket
350
time
2012-02-24 14:07:20