[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Comments on draft 6

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@x
Unicode weenies and / François Yergeaus.

Scheme-reports mailing list