[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)
|
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.