Re: [Scheme-reports] Comments on draft 6

[John Cowan <cowan@x>]

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@x>  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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports