On Sat, Mar 18, 2023 at 9:20 AM Marc Nieper-Wißkirchen <
xxxxxx@gmail.com> wrote:
> 2. There are no rationales provided for mutexes, condition variables, or interrupts.
Mutexes and condition variables are already in SRFI 18.
That's a point I should have made: why is SRFI 18 not in the list of superseded SRFIs? It's certainly possible to implement the thread features without making use of SRFI 18: indeed, the sample implementation does so.
There is no reason not to duplicate the rationale from SRFI 18; this SRFI should be as self-contained as possible.
> 4. Given that `shift` and `reset` are provided as a library, `control` and `prompt` should also be provided.
This is left to a future SRFI if people feel the need to have a
predefined control/prompt pair. Shift/reset seems to be much more
common.
In that case, references to control/prompt should be removed altogether.
> 7. A blank line is missing before (current-continuation-marks).
Where exactly?
At the point just before the definition of `current-continuation-marks`.
> 8. It's unclear what the use of `continuation-mark-key?` is. Under what circumstances would key objects be treated specially?
It can be used if you want to guard against not using the most
efficient way to use continuation marks in a given Scheme system.
In that case, why not simply require the use of key objects as generated here?
> 10. A blank line is missing before (curent-parameterization).
Where exactly?
See #7.
> 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).
I use the language and semantics from Chapter 10 of the R6RS Standard
Libraries here.
Chapter 10 makes no reference to exiting by invoking the initial continuation. If you mean to inherit the semantics of `exit` (which are slightly different in R6RS and R7RS), you should say so.
As things stand, a program that passes #f to its initial continuation exits normally rather than abnormally. (Section 8.2 of the main R6RS report also does not explain what happens when the initial continuation is invoked.)
> 15. It is unclear what the purposes of `exception-handler-stack` and `exception-handler` might be.
Current-exception-handler is already in SRFI 18; the
exception-handler-stack procedure can be used for inspection or for
low-level library code dealing with the exception system. SRFI 229
can be used to add meta information to the handlers.
In that case, `exception-handler-stack` should be exported from an (or the) inspection library.
> 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).
You can calculate the timeout at the point where you call
`thread-sleep!`, etc.
No, you can't. Necessarily the call to current-time happens before the call to thread-sleep, and there is no assurance that there is not an arbitrary lapse of time between the one and the other, as by a low-level (non-Scheme) interrupt.
By accepting relative times directly, the implementation can assure that there is no such delay. This is fundamental to the reliability of timeouts: a thread-join! whose timeout is now in the past will never time out, which is unlikely to be the intention.
Thank you for the extensive perusal of the last draft.
One more point that I noted but forgot to put in my email: the definition of %case-lambda-box-ref refers to %lambda-box-ref.