[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)
|
Vitaly Magerya scripsit: > Hi, folks. I've read draft-6, and here are some comments (it's mostly > editorial things). Thanks so much for this close reading. What follows reflects what I have already edited into draft 7. I or my fellow editors will take up your other points when we can. > Page 2, contents: it appears that "Alphabetic index of definitions > of concepts, keywords, and procedures" link points to page 75, not > page 77 (where the index is). This is true for both the link in the > contents, and the PDF bookmark. I'm not enough of a TeXnician to fix this one. Can someone else tackle it? > Page 5, section 1.3.1: the last two paragraphs of section 1.3.1 use > the word "implementation" five times in five sentences; can this be > rewritten somehow? Turned into an itemized list. > Page 6, section 1.3.2: "in addition to errors signalled by situations > [...]" -- is "signalled by situation" the correct usage? Shouldn't it > be "signalled in situations"? Fixed. > Page 6, section 1.3.2: what's the significance of "newly allocated" > here? This is the first time such a phrase is used in the report; > maybe a reference to another section that clarifies what it means and > why is it important will help? Index has no references to "newly" or > "allocation". Changed to "need not be distinct from objects previously used for the same purpose." > Page 6, section 1.3.3: vertical spaces between paragraphs are much > larger here than in any other place of the report; why is that? I have no idea. > Page 17, section 4.2.3: there are two missing ")" in the final > examples. Fixed. > Page 18, section 4.2.5: how does the use of "lazy" in the example > ensures that heap is not exhausted? This is the only example of it's > usage and it's not clear what it does here, or why is it generally > needed (it's definition on page 17 does not clarify either). Added clause "because {\cf force} will in effect force such sequences iteratively." > Page 18, section 4.2.5: in the same example, what is "heap" at all? > This is the only place in the report where this word is used. Changed "the heap" to "available storage". > Page 25, section 5.4: define-record-type is said to bind <name> to "a > representation of record type", but there does not seem to be anything > else you might do with it (correct?). What is the rationale for > introducing this binding? Does this mean I can't name the constructor > the same as the record type? It is bound to provide extensibility to the large language, which will include more complex kinds of records. You cannot name the constructor the same as the record type. > Page 32, section 6.2.4: "negative zero is an inexact value written > -0.0, which is distinct (in the sense of eqv?) from 0.0" and "however > numerical comparisons treat negative zero as equal to zero" -- but > eqv? on number is defined as numerical comparison (page 29, section > 6.1), so are they equal or not? They are equal in the sense of =, but distinct in the sense of eqv?. > Page 32, section 6.5.2: what is the rationale for short, single, > double and long inexact numbers? Are there implementations that > distinguish those? There are, notably Racket. The rationale is that actual hardware and low-level software implement these things. > Page 48, section 6.10: there's a missing ")" in the string-for-each > example. Fixed. > Page 55, section 6.13.4: is it intentional that "system interface" is > a subchapter of "input and output"? It was in R5RS, where the only procedures defined are load and transcript-{on,off}. With the wider variety of procedures present in R7RS, I've promoted it. > Page 56, section 6.13.4: does calling exit ignores dynamic-wind guards > and exception handlers? Filed ticket #344 about dynamic-wind guards. I don't see where exception handlers come into it: exit doesn't raise an exception. > Page 56, section 6.13.4: "[...] Scheme environments that can be passed > to eval" -- environment specifiers, not environments are passed to > eval. Fixed. > Page 56, section 6.13.4: it is an error to mutate any of the strings > returned by get-environment-variables; what about the whole alist? Fixed. > Page 56, section 6.13.4: what is the rationale of current-second > function, what are it's intended uses? I'm somewhat at a loss here. Most languages provide some variant of this functionality, but I can't find any specific rationales for it. > Page 56, section 6.13.4: what is the rationale for having > current-jiffy and jiffies-per-second functions? Why doesn't > current-jiffy return seconds directly? I've adopted an edited version of the CLtL2 rationale: The reason for allowing jiffies to be implementation-dependent is so that {\cf current-jiffy} can execute with minimum overhead. The idea is that it should be very likely that a compactly represented integer will suffice as the returned value. Any particular jiffy size will be inappropriate for some implementations: a microsecond is too long for a very fast machine, while a much smaller unit would force many implementations to return integers which must be allocated for most calls, rendering {\cf current-jiffy} less useful for accurate timing measurements. -- John Cowan <cowan@ccil.org> http://ccil.org/~cowan Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users have embraced efficiency but because markets are the best place to allow users to maximize their preferences, and very often their preferences are not for conservation of cheap resources. --Clay Shirkey _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports