On 9/22/22 11:45 AM, Bradley Lucier wrote:
>
> On 9/21/22 5:16 AM, Marc Nieper-Wißkirchen wrote:
>>
>> Am Di., 20. Sept. 2022 um 08:33 Uhr schrieb Marc Nieper-Wißkirchen
>> <xxxxxx@gmail.com <mailto:xxxxxx@gmail.com>>:
>>
>>     Am Di., 20. Sept. 2022 um 02:43 Uhr schrieb Bradley Lucier
>>     <xxxxxx@math.purdue.edu <mailto:xxxxxx@math.purdue.edu>>:
>>
>>     In fact, `array-copy` seems easy to specify correctly without any
>>     new language but it is not clear what the specification of
>>     `array-copy!` should be.  At the moment, it is the same as
>>     `array-copy` but this is obviously not intended.
>>
>>     I will think about a way how to specify the "!" versions.
>>
>>
>> Okay, I think I have a solution.  Once the non-"!" versions are
>> specified properly (using `array->list`, etc.), the "!" versions can
>> be defined with precisely the same semantics but with the following
>> addition: "It is an error if the continuation of each call to the
>> array's getter is invoked more than once."  (See the specification of
>> `letrec` in R6RS and R7RS where this language comes from.)
>>
>> When this is done, the comment about "call/cc-safety" can be left in
>> the non-normative section but the term isn't needed for the actual
>> specification anymore.
>>
>> Marc
>>
>
> (CC'ing the list.)
>
> With this commit:
>
> https://github.com/gambiteer/srfi-231/commit/7ecfd3c26cd596a40ccbe196478fcc06bf9c2cb5
>
> I've added a sentence along these lines to the Notes:
>
> https://htmlpreview.github.io/?https://github.com/gambiteer/srfi-231/blob/call/cc-fix/srfi-231.html#Notes
>
> With this change, I'm ready to ask Arthur to review this SRFI for
> finalization.
>
> Brad

After thinking about what changes, if any, should be made to the
specification of array-assign!:

https://srfi-email.schemers.org/srfi-231/msg/21609282/

I've come to believe that it was a mistake to say that "It is an error"
if the continuation of each call to the  array's getter is invoked more
than once.  It would be better to say that the behavior is "undefined"
or "implementation defined" instead of consigning such programs to the
bin.  I.e., people may have a reason to do such things in a particular
situation, but the program may not be portable.

That being said, given that "it is an error" in the SRFI, I think that
we should add to the specification of array-assign!
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
It is an error if the continuation of each call to source's getter or
destination's setter is invoked more than once.
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
and leave it at that.

Brad