R6RS says the following about the naming convention: "By convention,
the names of procedures that store values into previously allocated
locations (see section 5.10) usually end in “!”."

This is consistent with the use of "!" in R6RS, R7RS, SRFI 1, and SRFI 231.

I claim that R7RS's "map" is, in fact, "map" and not "map!" (why it is
so I argued on Chibi's issue tracker), so no problem here as well. The
same goes for vector-map, which must be offered as a purely pure
procedure by an implementation.

A suffix of "/cc" would be bad because it does not really have much to
do with call/cc but with the observability of mutation of the store.

Am Mi., 24. Mai 2023 um 04:08 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> This came up in a discussion on a chibi issue
> (https://github.com/ashinn/chibi-scheme/issues/904),
> but is worth bringing up on the list.
>
> R5RS had one use of the exclamation point, which
> was to indicate explicit mutation of a variable or
> storage location.
>
> SRFI 1 introduced the notion of linear update procedures,
> which effectively take ownership of their inputs.  They may
> or may not mutate those inputs, making the original
> values unusable.  This has both advantages and
> disadvantages.  It encourages a functional style of
> programming while allowing implementations freedom to
> optimize.  On the other hand, it makes it difficult to
> understand and predict memory usage.
>
> SRFI 1 chose to extend the use of the exclamation mark
> to linear update procedures.  This was a debatable choice,
> since linear update procedures behave in many ways the
> opposite of the R5RS mutation procedures.  The R5RS
> procedures have no return value, so they are always called
> as side-effecting and you later refer back to the input for
> the results.  For linear update procedures you must always
> use the returned value and can never refer back to the
> input.  You have to write in a functional style when using
> linear update and the implementation is encouraged not
> to mutate, yet everywhere you mark the procedures as
> using mutation.  But it's probably too late to change this
> convention.
>
> SRFI 231 introduces yet a new notion, this time of "call/cc
> safety."  The idea of this is that you can't detect internal
> state changes of a higher order function by using call/cc.
> Thus if you use map-in-order and the proc returns multiple
> times, each time it returns it will pick up where the continuation
> was captured, preserving any previous values and recomputing
> the rest.
>
> This property is not formally defined nor guaranteed by any
> existing standard procedure, but is not new, and is recognized
> as a generally useful property.  The standard definition of
> `map` is actually a `map-in-order` with this property.  On the
> other hand, neither the reference implementation nor most
> actual implementations of vector-map have this property.
>
> I'm not going to debate how important or useful call/cc safety
> it.  In the context of arrays I will likely never want it due to the
> impractical overhead it incurs, but others might want it.
>
> What concerns me is the naming.  SRFI 231 chose also to
> use the exclamation point for procedures _without_ this property.
> This introduces problems of 1. consistency, 2. naming conflicts,
> and 3. readability.
>
> 1. Consistency.
> By retroactive convention, for consistency, that would mean
> that R7RS `map` should in fact be named `map!`, although
> this is taken by the linear update version.  Similarly we must
> adjust `for-each!`, `filter!` and so on for all existing higher-order
> procedures.
>
> 2. Naming Conflicts.
> As noted above, we have conflicts with linear-update variants
> using the same naming convention, as well as explicitly mutating
> variants like `vector-map!`.  When working with very large arrays
> (which is trendy these days), conserving memory is of utmost
> importance, and explicit mutation can be desirable.  However,
> the `array-map!` name I want that behaves like `vector-map!`
> would likely be interpreted in a very different way in the context
> of SRFI 231.
>
> 3. Readability.
> ! stands out as a nice visual indication of mutation (or in the
> case of linear update potential mutation), but in the case of
> non-call/cc-safe procedures it's there even when the programmer
> is not mutating anything.  In particular, the inputs will never
> be mutated.  With all of these different interpretations, I feel
> the exclamation point loses its meaning.
>
> A simple counter proposal would be to instead adopt a new
> suffix for the new type of procedure that has been introduced.
> Thus we could append call/cc safe procedures with /cc or ∞.
>
> --
> Alex
>