Am Mi., 24. Mai 2023 um 10:28 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Wed, May 24, 2023 at 2:59 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>>
>> 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.
>
>
> Although Chibi's implementation has the desired property, it is
> not guaranteed by the standard.  One could imagine map in an
> implementation with cdr-coded lists not having this property.

The standard guarantees it because this is what the prose says in the
description of map and vector-map.  The standard is very precise about
noting when previously allocated locations in the store are mutated.
What one has to make explicit while reading the prose is the
continuations ("then" and the like in English and "kappa" in the
formal semantics).

>> 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.
>
>
> I'm open to other suggestions :)

Well, R6RS suggests "!".

I see more of a problem in SRFI 1's convention. The suffix "!" only
conveys half the meaning, namely that the store may be modified. What
is not conveyed, but equally important, is that the result value needs
to be used (not the argument's value after the call). Trying to find a
better naming convention for linear-update procedures like reverse!
appears more important to me.

Marc

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