1. Given the size of this SRFI, a table of contents is desirable.
2. There are no rationales provided for mutexes, condition variables, or
interrupts.
3. It is unspecified whether prompt tags are a disjoint type. (I believe
they should be.)
4. Given that `shift` and `reset` are provided as a library, `control` and
`prompt` should also be provided.
5. The definition of `guard` uses `define-syntax/who`, which is not
explained anywhere.
6. In 4.9.1, it is said that the most recent annotation prevails if there
is more than one with the same key. Why should this be? I should
think that raising an error is preferable.
7. A blank line is missing before (current-continuation-marks).
8. It's unclear what the use of `continuation-mark-key?` is. Under what
circumstances would key objects be treated specially?
9. Parameters should support multiple values. This would mean that in
addition to `make-parameter` and `make-thread-parameter`, the procedures
`make-multiple-value-parameter and make-multiple-value-thread-parameter`
would be needed. The simplest approach is that rather than an *obj*
argument, there would be a *thunk* argument, which would return the values
to be placed in the parameter. By the same token, the clauses of
`parameterize` and `temporarily` could allow either (parameterize ((foo 1 2
3)) <body>) or else (parameterize ((foo (values 1 2 3)) <body>). The
latter is safe because `values` wouldn't otherwise make sense here.
10. A blank line is missing before (curent-parameterization).
11. In 4.12, the reference to "the initial continuation" should be "an
initial continuation", since the previous paragraph specifies that there
may be any number of initial continuations.
12. In the same place, "exits normally" should just be "exits", as the
semantics of normal and abnormal exits from a top-level program is
unspecified. In particular, a top-level program that passes #f to its
continuation may be equivalent to calling (exit #f).
13. The incompatibility of `delay` and `force` in this SRFI with R7RS also
applies to R6RS.
14. It would be better, given these incompatibilities, to use new names
rather than overloading `delay` and `force`.
15. It is unclear what the purposes of `exception-handler-stack` and
`exception-handler` might be.
16. A relative timeout is not equivalent to the value of (current-time)
incremented by the relative value, because relative timeouts are relative
to the time when the procedure `thread-sleep`, `thread-join!`,
`mutex-lock!` or `mutex-unlock!` is called. This by definition will not be
the same as the time when `current-time` is called. I believe the Right
Thing is to split the four procedures in two, one accepting an absolute and
the other a relative timeout, e.g. `thread-sleep!` and `thread-sleep-for!`,
or alternatively `thread-sleep-until!` and `thread-sleep!` (and likewise
for the other three).
17. I see no reason to use opaque time objects rather than integral numbers
of jiffies.
18. In the first "Note:" paragraph of `mutex-unlock!`, for "and" read "or".
19. To the "Note:" paragraph of 4.17.4, add "In addition, condition
variables are unrelated to conditions."
