On Fri, Sep 30, 2022 at 3:32 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
In the last draft (#2), all changes based on all comments and > extensive reviews on the mailing list so far were incorporated. Since > then, there was no more discussion. Thus, I would propose to declare > finalization in a week. On the other hand, should more than editorial > changes become necessary during this period, we would see the third > draft instead. > 1. I strongly recommend that a faithful implementation of CL's `unwind-protect` be added to this SRFI. Scheme programmers have a tendency to treat `dynamic-wind` as if it served the same purpose, which it does not; making it available under its own name will encourage its proper use. The definition is available at <http://clhs.lisp.se/Body/s_unwind.htm>. 2. It seems to me that having an iterator for the empty list that returns an iterator for the empty list as its second value is easily misused. A failure to check for the first value being #f causes an infinite loop. Instead, the second argument should be a thunk that raises an error. 3. I recommend switching timeouts from seconds to jiffies, so as to maximize the use of cheap fixnum arithmetic. Exact integers are real, of course, but a second is a long time. 4. I don't think that &thread-timeout is necessarily an &error or even &serious; for example, you may be running a background thread to do work for a while, but want to cut it off if it runs too long. It should be a direct subtype of &condition. 5. I recommend the addition of a simple thread-runner facility. A thread-runner is an opaque object with which threads can be registered by passing it as an optional argument to `make-thread!`. The procedure `with-thread-runner` takes a procedure *proc* and invokes it with a newly allocated thread-runner. The purpose of `with-thread-runner` is to keep the forking and joining of threads within the lexical scope of *proc*, so as to avoid thread-level spaghetti code. When *proc* returns, `with-thread-runner` waits for all registered threads to terminate normally or abnormally, and then returns a list of the threads in arbitrary order. It is then possible to use `thread-wait` on any of these threads to extract their results. `With-thread-runner` should perhaps take a second, optional, argument which is a timeout. Acknowledgement: the Python library Trio. =========== The following unnumbered points are editorial. Spelling errors (I don't know if Arthur does a spellcheck or not): compatiblity -> compatibility <formals>s -> <formals> <body>s -> <bodies> interthread -> inter-thread multithreaded -> multi-threaded Need whitespace after `make-parameter` in the first sentence of its definition parametrization -> parameterization reparameterized -> re-parameterized sublibraries -> sub-libraries In addition, I suggest "singularized -> are in the singular" and "is a special form" -> "is syntax". "Instate" is a known English verb, but it is rare: "install" is clearer. "the call-with-non-composable-continuation defined here is a conservative extension of the call-with-non-composable-continuation of earlier Scheme reports": I think the second instance should be "call-with-current-continuation". Is there any reason to use "parameterization" (as a concrete noun) rather than "dynamic environment"? If the two are being used in distinct senses, I don't see it. (This change would affect the names of certain procedures.) The claim that the SRFI's definition of make-promise breaks R7RS compatibility should be removed, because adding new arguments to a procedure is backward compatible in all RnRS except R6RS. Add a note to 5.12.4 that "condition variable" is a misleading term, as it is not a variable but an object. It's rather hard to figure out what library or libraries a given identifier is contained in. Having found the relevant identifier, one has to search back arbitrarily far in the document to find the relevant library. I recommend a single mapping table somewhere in the SRFI, either in the style of the R7RS appendix or an inversion of it.
