[Scheme-reports] Comments on draft 6 Vitaly Magerya (18 Feb 2012 15:31 UTC)
Re: [Scheme-reports] Comments on draft 6 Jussi Piitulainen (18 Feb 2012 15:56 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (18 Feb 2012 23:16 UTC)
Re: [Scheme-reports] Comments on draft 6 Alex Shinn (19 Feb 2012 05:24 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (19 Feb 2012 19:23 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (19 Feb 2012 22:39 UTC)
Re: [Scheme-reports] Comments on draft 6 Vitaly Magerya (20 Feb 2012 15:53 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (20 Feb 2012 18:50 UTC)
Re: [Scheme-reports] Comments on draft 6 Vitaly Magerya (21 Feb 2012 15:34 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (21 Feb 2012 16:25 UTC)
Re: [Scheme-reports] Comments on draft 6 Alex Shinn (23 Feb 2012 01:27 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (23 Feb 2012 03:27 UTC)
Re: Comments on draft 6 Arthur A. Gleckler (21 Feb 2012 05:39 UTC)
Re: Comments on draft 6 Arthur A. Gleckler (21 Feb 2012 06:29 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (22 Feb 2012 22:34 UTC)

Re: [Scheme-reports] Comments on draft 6 John Cowan 22 Feb 2012 22:34 UTC

Arthur A. Gleckler scripsit:

> 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?

Editorial ticket #346 filed.

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

Editorial ticket #347 filed.

> | 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")?

I have changed this to: "If the handler returns, a secondary exception
is raised in the same dynamic extent as the handler.  The relationship
between the \var{obj} and the object raised by the secondary exception
is unspecified."

There is also the following, which I take to be in effect one comment:

> | Page 23, section 5.1: "program parts other than expressions that
> | are present at the top level of a program can be interpreted
> | declaratively" -- what does it mean for program parts to be
> | "interpreted declaratively"? What's the difference between this,
> | and expressions, which are "interpreted imperatively"?
> |
> | Further on page 24 (section 5.2.1) it is said that "at the top level
> | of a program, a definition [...] has essentially the same effect
> | as the assignment expression", which further increases my confusion
> | about what is "declarative" and what is not.

Editorial ticket #348 filed.

--
H�ggledy-p�ggledy / XML programmers            John Cowan
Try to escape those / I-eighteen-N woes;        http://www.ccil.org/~cowan
Incontrovertibly / What we need more of is      cowan@ccil.org
Unicode weenies and / Fran�ois Yergeaus.