|
Last-call comments on SRFI 226
John Cowan
(18 Mar 2023 01:30 UTC)
|
|
Re: Last-call comments on SRFI 226 Marc Nieper-Wißkirchen (18 Mar 2023 13:20 UTC)
|
|
Re: Last-call comments on SRFI 226
John Cowan
(18 Mar 2023 14:54 UTC)
|
|
Re: Last-call comments on SRFI 226
Marc Nieper-Wißkirchen
(18 Mar 2023 15:13 UTC)
|
|
Re: Last-call comments on SRFI 226
Arthur A. Gleckler
(18 Mar 2023 15:59 UTC)
|
|
Re: Last-call comments on SRFI 226
Arthur A. Gleckler
(18 Mar 2023 18:58 UTC)
|
|
Re: Last-call comments on SRFI 226
Marc Nieper-Wißkirchen
(20 Mar 2023 07:06 UTC)
|
Am Sa., 18. März 2023 um 02:31 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > 1. Given the size of this SRFI, a table of contents is desirable. I will accept a contribution that provides such a table of contents. > 2. There are no rationales provided for mutexes, condition variables, or interrupts. Mutexes and condition variables are already in SRFI 18. I will add a sentence about the addition of interrupts. > 3. It is unspecified whether prompt tags are a disjoint type. (I believe they should be.) It is unspecified on purpose. It is left to a future standard to possibly specify that prompt tags must be a disjoint type. (As has already been observed several times, the phrase "is a disjoint type" without reference to a well-defined universe of types is, at least, debatable.) > 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. > 5. The definition of `guard` uses `define-syntax/who`, which is not explained anywhere. Fixed. > 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. Continuation marks are like parameters in this regard. > 7. A blank line is missing before (current-continuation-marks). Where exactly? > 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. > 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. I thought about this but eventually decided against it. As you also observe, the `make-parameter` procedure cannot be (easily) extended to support multiple parameter values. The same is true for changing parameters by calling the parameter with one argument. As parameters can be seen as implicit arguments to procedures and can even be realized by variable-like entities (fluids), there are also semantic reasons why multiple-valued parameters may be a wrong extension. > 10. A blank line is missing before (curent-parameterization). Where exactly? > 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. Good point, fixed. > 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. > 13. The incompatibility of `delay` and `force` in this SRFI with R7RS also applies to R6RS. R6RS does not have the notion of parameters, moreover delay and force are only in the R5RS compatibility library of R6RS. > 14. It would be better, given these incompatibilities, to use new names rather than overloading `delay` and `force`. In the vast majority of use cases (probably all that do not explicitly try to demonstrate the incompatibility), the change will not matter (or will make the code more robust). As we have namespacing thanks to the library system, I don't see an advantage in giving delay and force new names. In fact, I would see it as a disadvantage. > 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. > 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. A future library may implement `thread-sleep-for!` using this idiom. > 17. I see no reason to use opaque time objects rather than integral numbers of jiffies. SRFI 226 leaves it open whether a time object is represented by an integer. I wouldn't want to enforce it because implementations that provide truly opaque objects can provide a bit more type-safety. > 18. In the first "Note:" paragraph of `mutex-unlock!`, for "and" read "or". Thanks! Fixed. > 19. To the "Note:" paragraph of 4.17.4, add "In addition, condition variables are unrelated to conditions." Added. Thank you for the extensive perusal of the last draft. The fixes are now in my personal git repo: https://htmlpreview.github.io/?https://github.com/mnieper/srfi-226/blob/master/srfi-226.html -- Marc
