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

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>