Am Sa., 13. Aug. 2022 um 20:15 Uhr schrieb Lucier, Bradley J
<xxxxxx@purdue.edu>:
>
> Arthur has issued a new draft of the SRFI document, with many associated changes to the implementation.
>
> I believe that all procedures whose names do not end with “!” are now call/cc-safe.  This rewrite improved the code in a number of ways, and I believe it should satisfy most of Marc Nieper-Wißkirchen’s concerns.

Thank you a lot for your extensive work!

> I included the following statement in the Notes section of the SRFI document.  I’m not entirely happy with it, but I think it’s a good start:
>
> This SRFI and call-with-current-continuation: The Scheme procedure call-with-current-continuation captures and encapsulates as a procedure the continuation of the current computation, which, perforce, includes a certain amount of state that consists of the values of captured variables, some local, some global, at the point the continuation is captured. This captured procedure can be invoked multiple times, as any procedure can.

I would not say that call/cc is associated with state. Call/cc itself
is completely pure (in the sense of functional programming). It is
usually call/cc together with mutation that needs careful coding.
(Mutation alone needs careful coding, but call/cc is a multiplier of
mutation fragility).

> We say a procedure in this library is call/cc safe if it is written in such a way that if captured continuations are invoked multiple times, then each invocation does not execute any library code that modifies any captured local variable state accessible to another invocation of a continuation (either itself or a different captured continuation). Because procedures passed as arguments are not within the lexical scope of code in this library, these procedures cannot modify the state of these local variables, either.

I think that finding a precise definition of "call/cc-safety" is
crucial - not only for this SRFI but also for other parts of Scheme
that include higher-order procedures. I think what you call
"call/cc-safety" is a notion of (relative) purity of a higher-order
procedure.

A relatively pure higher-order procedure becomes a pure procedure when
applied to pure procedures, but this is not all. A relatively pure
higher-order procedure has to behave well even when applied to impure
procedures.

I have to think about it a bit more.

> I figure if the R6RS and R7RS editors (of which I was one) didn’t get the definition of call/cc-safe precisely correct (in their description of vector-map, string-map, etc.), then I don’t feel too bad about taking a shot at it in a lowly SRFI.

I agree with you; that the result (of vector-map, string-map, ...) is
not mutated once returned should only be a necessary condition, but
not a sufficient one.

Marc