#10 – Declaring supported features to cond-expand in libraries – r7rs

Now that we have many more syntactic abstraction facilities available in the large language so we don’t need to upgrade cond-expand. (Adding more and more to define-library what cannot be reduced to existing concepts is IMO opposite to the most cited guiding principle of the Scheme language.

For a better way, see Chez’s meta-cond for a possible form and implementation how to test for user-and library-defined features at compile-time: meta-cond

In your example above, Daphne, (scheme regex) would export an ordinary variable non-greedy with value either #t or #f and which can be tested against using meta-cond, for example.

That said, most libraries should have a stable set of capabilities. When a breaking change is introduced, it makes more sense to bump a version number.

Now that we have many more syntactic abstraction facilities available in the large language so we don’t need to upgrade `cond-expand`. (Adding more and more to `define-library` what cannot be reduced to existing concepts is IMO opposite to the most cited guiding principle of the Scheme language.

For a better way, see Chez’s `meta-cond` for a possible form and implementation how to test for user-and library-defined features at compile-time: [meta-cond](https://cisco.github.io/ChezScheme/csug9.5/syntax.html#./syntax:h9)

In your example above, Daphne, `(scheme regex)` would export an ordinary variable `non-greedy` with value either `#t` or `#f` and which can be tested against using `meta-cond`, for example.

That said, most libraries should have a stable set of capabilities. When a breaking change is introduced, it makes more sense to bump a version number.