Would it be fair to say that this description of an alternative approach is
a good start for a discussion worth having within the SRFI process proper,
or is it proposed in opposition to having such a SRFI at all? Although
virtually every implementation has a way to map its library space to the
file system space, I could not find any public record of a process that
formalized it, even though common approaches definitely exist.

I do not insist on starting the discussion under the SRFI I planned to
propose. Your approach, if made into a SRFI, would be as good.

-S

On Monday, September 28, 2026 10:40:10 AM (-04:00), Peter McGoron - peter
at mcgoron.com (via srfi-discuss list) wrote:

 > Personally, I prefer the "wrapping define-library" solution. Reading the
define-library does not seem like it would be that much of a performance
drag, especially if it is deferred until library invocation time.
 >
 > The library mask file (as far as I can tell reading it) has the drawback
that all information is in a single database, so composing multiple library
paths together would be difficult.
 >
 > I'm uncertain how many implementations actually allow for something like
 >
 >     (cond-expand
 >       ((not full-numeric-tower))
 >       (else
 >        (define-library (my library)
 >          ...)))
 >
 > Adding a new define-library for might be easier and makes it little less
convoluted:
 >
 >     (define-library (my library)
 >       (cond-expand
 >         ((and srfi-NNN (not full-numeric-tower)) (hide))
 >         (else))
 >       ...)
 >
 > If the search system for (library ...) encounters a library that is
hidden, it returns #f for that cond-expand feature, and if it tries to load
a hidden library, it signals an error.
 >
 > Of course, cond-expand into a define-library has the benefit that it
doesn't have to modify the library syntax. (Times like this would make you
wish for a macro system that worked for library definitions...)
 >
 > -- Peter McGoron