Rather than doing this, I would prefer to provide `assertion-violation`, `assertion-violation`, and  `assert` from R6RS in a different SRFI.  The last is syntax and therefore has access to the form to be evaluated, so that it can construct its own messages.

If a procedure contains (assume (pair? x)), then the compiler may indeed assume that and go wrong if x is not a pair, but it may also signal an error or do something else.  Per contra, (assert (pair? x)) is guaranteed to signal an error satisfying `assertion-violation?` if x is not a pair.  It's then straightforward to change one to the other, or in debug mode to have `assume` unconditionally invoke `assert`.

Few, if any, R7RS implementations have a way to add features other than those the implementation already provides.

On Sat, Jul 11, 2020 at 12:34 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Am Fr., 10. Juli 2020 um 16:39 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

> If you want, we can add a post-finalization note to SRFI 145 (or amend
> SRFI 145 in some other way), which specifies that "assume" must signal
> an error unless a feature identifier "unsafe" (or "ndebug" or
> whatever) is set. Or (following SRFI 145's sample implementation) when
> the "debug" feature identifier is set. Implementations shipping SRFI
> 145 are then encouraged to set "debug" by default unless some highly
> optimized build is asked for.
>
> The good thing about passing this on to SRFI 145 (or a successor) is
> that we have a central place to handle this issue, which will come up
> in subsequent SRFIs as well. And implementers of SRFI 189 will know
> that they just have to use the last implementation.

Thinking about it a bit more, I propose the following changes for a
replacement to SRFI 145:

1) Add a predicate "assumption-error?" and a procedure
"assumption-error-irritants".
2) If the feature identifier "debug" is present, "assume" must signal
an error that fulfills "assumption-error?" with the provided irritants
in case its argument evaluates to #f.
3) If the feature identifiers "debug" and "ndebug" aren't present,
"assume" should report a non fulfilled assumption to the user in an
implementation-depended way.
4) If the feature identifier "debug" is not present but "ndebug" is,
the behavior of unfulfilled assumptions is implementation-dependent.
5) Implementations are encouraged to set the feature identifier
"debug" by default.

We would get the best of both worlds if with this change to SRFI 145,
"assume" would be used in "maybe-if" and "maybe-and". The same holds
for future SRFIs.

What do you think?