Am Sa., 11. Juli 2020 um 20:44 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> 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.

We can add this to the proposed change to SRFI 145. And make "assume =
assert" in case of the debug feature identifier set.

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

For the purposes of SRFI 189, we don't want an unconditional 'assert',
though. What we want is an 'assume' that delegates to 'assert' unless
we ask for an optimized build.

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

Not at all. There is, for example, SRFI 138, whose "-D" argument is
supported by a number of implementations (Chibi, Larceny, Sagittarius,
...).