Email list hosting service & mailing list manager

Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types (no sender) (11 Jul 2020 16:34 UTC)

Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 16:33 UTC

Am Fr., 10. Juli 2020 um 16:39 Uhr schrieb Marc Nieper-Wißkirchen

> 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
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?