"Undefined" is the same as "is an error", I think.

"Unspecified" is a best term IMO.  "Implementation-defined' asks for
implementation defining it.

Am Fr., 3. Feb. 2023 um 19:37 Uhr schrieb Bradley Lucier <xxxxxx@purdue.edu>:
>
> 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