Note that cond-expand throws an error if the feature requirement is not satisfied, so if you don't need to customize the error message,
(cond-expand ((library (srfi N)))) should suffice the purpose.

And it should be the canonical way to check srfi availability.  If an implementation supports srfi-62 but doesn't check it with cond-expand, you should file an issue.





On Wed, Mar 28, 2018 at 6:59 AM, Ciprian Dorin Craciun <xxxxxx@gmail.com> wrote:
On Wed, Mar 28, 2018 at 7:44 PM, Shiro Kawai <xxxxxx@gmail.com> wrote:
> In R7RS, you can use 'library' feature requirement of cond-expand to ensure
> the implementation provides srfi N:
>
> (cond-expand ((library (srfi N))))




Yes, I've missed that feature of `cond-expand`.  Therefore listing
`srfi-n` in `(features)` is not required.




However its usage for "hard-requirement" of a particular library, like
say SRFI 62 for comment values, would be cumbersome, as there is no
"alternative" solution.

Therefore one would have to write (and I had missed the `not` on the first try):

  (cond-expand ((not (library (srfi 62))) (error "comment values not
supported")))

Instead of just:

  (import (srfi 62))

Moreover Chibi fails in using the `cond-expand` above even though it
does support it.




My point was this:  requiring any SRFI to be importable provides a
sense of "universality" and "uniformity" in not having any "special"
SRFI's (at least from the point of view of the user);  moreover it is
trivial for any Scheme implementation that implements a "special" SRFI
to just allow its importing without anything actually happening.  (In
fact in case of Chibi I think it's just a matter of creating an empty
file in the library path.)

I won't push any further on this subject, as it was just an
observation.  (Perhaps triggered by my OCD...)  :)

Ciprian.