Am Sa., 17. Sept. 2022 um 16:39 Uhr schrieb Bradley Lucier < [email protected]>: > > On 9/14/22 2:48 AM, Marc Nieper-Wißkirchen wrote: > > > > Am Di., 13. Sept. 2022 um 23:17 Uhr schrieb Bradley Lucier > > <[email protected] <mailto:[email protected]>>: > > > > Thank you for your comments, I think I'll leave the current description > > as it is. > > > > > > There are still three issues with the current description: > > > > - It says that the sample implementation implements the procedures > > without a "!" in a "call/cc-safe" way. But that should be part of the > > specification, i.e. that every conforming implementation must implement > > the procedures without a "!" in a "call/cc-safe" way. > > What should I say, that "it is an error" if the implementation does not > implement the procedures without "!" in a call/cc-safe way? Instead of > what it says now:
"It is an error" is usually used in the context of the user, not in the context of the implementation. I would just write: "The procedures without a `!' are call/cc-safe." This seems to be the language used in the reports and most SRFIs. > > - I find the current description more complicated than necessary (and > > too focused on call/cc, which is not the cause but just a means of > > detecting mutation), but that opinion is certainly subjective. More > > importantly, however, is that it is not clear how to prove that the > > definition of "call/cc-safety" in SRFI 231 forbids all mutations that we > > want to be forbidden, e.g. mutating a result returned earlier. > > I don't think we're going to solve this problem here. As I said, I > decided to emphasize how I rewrote the routines to be "call/cc safe"". > Not mutating a result returned earlier is a necessary, not a sufficient > condition to be call/cc safe. Is it clear that the latter condition follows from your definition of "call/cc-safety"? > > > - It would be good if the SRFI used the language of the standard Scheme > > semantics, i.e. that it talks about storing values in locations in the > > store and not about "modifying the state of data". > > "Storing values in locations in the store" is not the problem---as long > as those locations are newly allocated. "Storing values in existing locations" then. If I read the formal semantics of R7RS correctly, there is unfortunately no semantic primitive of allocating a filled location in the store. > > Again, I don't see that we're going find the language to solve the > general issue in this SRFI, as it hasn't been solved (at least to my > knowledge) in any R*RS so far. This does not mean that it shouldn't be solved. :) Here is a slight modification of `vector-map' from R7RS: ** (vector-map PROC VECTOR1 VECTOR2 ...) The vector-map procedure first applies PROC element-wise to the elements of the VECTORs, then newly allocates a vector of the results in order and finally returns it. If more than one vector is given and not all vectors have the same length, vector-map terminates when the shortest vector runs out. The dynamic order in which proc is applied to the elements of the vector s is unspecified. Note: As the returned vector is allocated in the continuation of the final invocation of PROC, it follows that if multiple returns occur from vector-map, the values returned by earlier returns are not mutated. Note: The vector returned in the continuation of an invocation of PROC has as its corresponding element the result of this invocation of PROC. ** I think it captures all that's needed or wanted. The main point is that the temporal relationship in the English prose corresponds to the continuation concept of evaluation. In other words, when we say that procedure A is invoked after procedure B, it means that the invocation to A happens in the continuation of the invocation to B. A similar wording as in `vector-map` could be used for `array->list`, which, in turn, is used to define many other procedures, for example. But, as you said, there are many more places we will have to go through before the next language standard. Thanks for reading, Marc
