On 9/14/22 2:48 AM, Marc Nieper-Wißkirchen wrote:
>
> Am Di., 13. Sept. 2022 um 23:17 Uhr schrieb Bradley Lucier
> <xxxxxx@math.purdue.edu <mailto:xxxxxx@math.purdue.edu>>:
>
>     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 intended that all procedures in this library whose names do not
end with an exclamation point (!) be implemented in a call/cc-safe way."

> - 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.

> - 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.

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.

Brad