[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Comments on draft 6
- To: Vitaly Magerya <vmagerya@x>
- Subject: Re: [Scheme-reports] Comments on draft 6
- From: "Arthur A. Gleckler" <scheme@x>
- Date: Mon, 20 Feb 2012 22:28:51 -0800
- Cc: scheme-reports@x
- In-reply-to: <CAL409KxSN9DoAaDSi14g=-_G22QzKfqOymb=7UtfU-nu5-LOvg@mail.gmail.com>
- References: <CAL409KxSN9DoAaDSi14g=-_G22QzKfqOymb=7UtfU-nu5-LOvg@mail.gmail.com>
| 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?
| 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.
| 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.
| 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."
| 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.
| Page 31, section 6.2.2: "(/ 3 4)" _expression_ should all be on the
| same line.
Fixed.
Thanks again for your detailed review. I believe we've responded to
every comment except these, which we will get to soon:
| Page 27, section 5.5.1: "begin declaration takes a list of expressions
| and declarations to be spliced literally" -- since library form
| does not allow expressions or definitions outside of begin form,
| what is being spliced, and into what?
| Page 48, section 6.10: "the effect of passing no value or more than
| one value [...] is unspecified" -- doesn't this contradict page 71,
| where it says "programs are now explicitely permitted to pass zero
| values or more than one to continuations that discard them"?
| Page 50, section 6.11: "if the handler returns, an exception is
| raised in the same dynamic extent as the handler" -- is the same
| exception raised to another one (i.e. what is "an exception")?
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports