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

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
 >