I have to agree with Sergei about the merits of the phrase "it is an error".

Am Di., 16. Dez. 2025 um 04:48 Uhr schrieb Sergei Egorov <xxxxxx@acm.org>:
>
>
> Wolfgang, you are right, there is always confusion about the exact meaning
> of these phrases; that's why most standards explain them in the prologue. I
> thought that the least I can do is not to exacerbate the situation by
> inventing terms of my own -- the newcomers will most likely stumble upon
> the "an error" definition in some Scheme report.
>
> The way I see it informally is that "an error" is a sort of contract
> between users and implementers. Users promise not to write code described
> as "an error", or at least not to do it blindly, understanding that at a
> very minimum such code is not portable. Implementors promise to put a
> reasonable effort to warn the users about the erroneous situation, where
> reasonable effort is weighted against the goals of the implementation.
> Later standards may shift the balance: e.g. earlier Scheme standards
> described map over list of unequal length "an error", later ones require
> implementations to stop when the shortest list ends (it still should be a
> proper list though).

NB R6RS requires implementations to report a violation if the lists
are of unequal length, so in spirit, it continues to "be an error" in
R6RS. (I hope that R7RS-large will follow R6RS, not -small here, for
the sake of reducing hard-to-detect programmer errors.)

>
>
> On Monday, December 15, 2025 8:24:48 PM (-05:00), Wolfgang Corcoran-Mathe
> wrote:
>
>  > Sergei,
>  >
>  > On 2025-12-16 00:16 +0000, Sergei Egorov wrote:
>  > > This is not an absolute implementation freedom the "undefined
>  > > behavior" phrase is traditionally used for in programming language
>  > > specification context; "an error" encourages the implementors
>  > > to detect and report, although it stops short of making it a
>  > > requirement. It allows non-portable extensions, thus giving
>  > > implementors room for experimentation. Catastrophic failure is
>  > > mentioned as the last choice, not a preferred one.
>  > >
>  > > Switching to UB would mean that I don't want any of those
>  > > things, which is not just a simple editorial change. I do want
>  > > implementations to detect and report if it does not go against
>  > > other considerations such as simplicity or performance.
>  >
>  > I'm not at all a veteran of language specification, so I'll take your
>  > word that "undefined behavior" has the connotation you say it has.
>  > The "it is an error if X" language does convey the idea that X is
>  > an erroneous situation.  But X may not be an erroneous situation in
>  > every implementation, in particular those that provide a non-portable
>  > extension.  From many years of Scheme IRC discussion I can say that the
>  > Reports' "erroneous situations which may or may not be errors" cause
>  > a small amount of confusion for newcomers.  Designating a situation
>  > erroneous (even if that's just the connotation of the phrase & not
>  > in the formal definition of terms) is confusing when implementations
>  > are allowed to treat it as normal.  At least "undefined behavior"
>  > creates no expectations at all.  (Or does it?)
>  >
>  > In any case, I think the choice should be up to the SRFI author.
>  > All of the published Reports except R6 use "it is an error", & the
>  > only one to use "undefined behavior" is incomplete.  It's perfectly
>  > acceptable--and maybe preferable--to use the language of any existing
>  > Report, especially when the meaning of that language is familiar to
>  > most experienced Schemers.
>  >
>  > Wolfgang
>  >