Email list hosting service & mailing list manager


Re: How to "signal" (or "require") that a certain Scheme implementation provides a certain SRFI Ciprian Dorin Craciun 28 Mar 2018 16:59 UTC

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.