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".

> | Page 26, section 5.5.1: library name can contain "unsigned exact
> | integers" -- maybe "nonnegative" instead of "unsigned"? Also, are
> | there limits on which integers an implementation can represent
> | exactly, i.e. can I be sure that 802000 is exact?
>
> I've made the change to "nonnegative."
>
> Section 6.2.3 Implementation restrictions gives the requirements for
> exact integers:
>
>   An implementation of Scheme must support exact integers throughout
>   the range of numbers permitted as indexes of lists, vectors,
>   bytevectors, and strings or that result from computing the length of
>   one of these.
>
> So whether 802000 is exact is implementation-dependent, but should be
> easy to determine.

Right. I know I'm being too pedantic here, but I still want to point
out that I can't name my library (lib 802000) and expect the name
to work everywhere: the report allows, but does not guarantee that
it's a valid library name.

> | Page 27, section 5.5.1: "however a REPL should permit these actions"
> | (redefinitions) -- this paragraph this paragraph started talking
> | about top level and libraries, but then mentioned REPL. Are "top
> | level" and "REPL" interchangeable?
>
> The "REPL" and its relationship with the "top-level" environment are
> defined in 5.1 Programs.

Right. The paragraph I'm curios about is this (pages 26-27):

  The top level of a program may also include import declarations.
  In a library declaration, it is an error to import the same
  identifier more than once with different bindings, or to redefine
  or mutate an imported binding with define, define-syntax or set!.
  However, a REPL should permit these actions.

So, overlapping imports, redefinitions, etc. are not allowed in
library declarations, allowed in the REPL, but what about the top
level? The paragraph above should say something about top level.

> | Page 27, section 5.5.1: "the top-level expressions in a library" --
> | maybe this can be reworded somehow to avoid term mixture? (It is
> | not explained if there is such a thing as a top level in a library).
>
> I've changed that sentence to "When a library is loaded, its outermost
> expressions are executed in textual order."

I guess it's better.

> | Page 28, section 5.5.2: the example on this page displays some
> | control characters to "clear vt100". Should I argue why such things
> | do not belong in this report?
>
> I'm not sure why that doesn't belong in the report.  It's an example.
> The comment makes it clear what is happening.

Not every terminal is vt100-compatible (although that sequence is
rather portable), not every scheme outputs to a terminal, not every
scheme can output to a terminal (e.g. DrRacket), and not all operating
systems even have such a concept (e.g. Windows). What if I'll want
to run the example?