Am So., 23. Okt. 2022 um 00:54 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Tue, Oct 18, 2022 at 2:22 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
>>
>> I'm partial to the convention that has become common in recent SRFIs:
>>
>> srfi-${N}/srfi/${N}.sld
>>
>> It's concise and clear.
>>
>> Often, authors put tests at the srfi-${N}/ level, e.g. at srfi-${N}/srfi-${N}-test.scm. I'd rather see them under the srfi directory, without a "srfi-" prefix, e.g. at srfi-${N}/srfi/${N}-test.scm. I don't think that should cause problems with loading the tests when they're not needed.
>>
>> What do people think of that convention?
>
> Marc Feeley has given feedback on this convention, which is the most popular pattern in recent SRFIs.  Does anyone else have an opinion?  I plan to document and recommend the convention in srfi-template.html in the Implementation section unless there are strong objections.

I already mentioned why "srfi-${N}/lib/srfi/${N}.sld" would be the
better convention because it clearly separates a part of the directory
structure containing library definitions and only library definitions.
This matters because of the way implementations usually scan
directories for library definitions. We want to make sure that they
don't pick up files that are not meant to be loaded by an
implementation.

Also, I want to remark that any convention officially mentioned should
not neglect R6RS. The proposal so far applies solely to R7RS.

I would also like to repeat my point that the domain of SRFIs and
their implementations should be a different one than the domain of
portable (published) libraries outside of the Scheme core.  We should
first make the latter easier to use and load into Scheme
implementations before possibly amending SRFI policies.  Maybe we can
reuse the infrastructure that has been built to support SRFIs to get a
parallel process for announcing and publishing portable libraries
running.  For example, some have mentioned that it might have made
sense to turn SRFI 233 into a portable library outside the Scheme
process because it is an extension of the Scheme language only in a
very loose sense. (I don't want to discuss this specific SRFI here; it
just serves as an example here. My own SRFI 161 may be another one.)
Now, if there had been infrastructure for portable libraries like what
we have for SRFIs, the authors of SRFI 233 would have had a genuine
choice. They would have had a separate place to the SRFI repository to
announce, discuss, document, and publish their library.

So, let's start a sister process to SRFIs (under the technical SRFI
roof) where it is actually the idea to use the provided library
implementations unmodified.  At first, we need a namespace like
"srfi".  An interesting choice would be "from".  Every author or
organization, or proposal can then request to be assigned a
second-level name, e.g. "mnw".  So the import form would be "(import
(from mnw unifiable-boxes))".  Of course, any other form of library
name generation would also be possible (see below for other possible
initial name parts).  The main point is that this library repository
would already have a community around it and would have the same
documentation, discussion, and archival infrastructure known from the
SRFI process.

SRFI stands for "scheme request for implementation".  This does not
describe a portable, finished library very well.  If one wants to
surf, one needs skill. So why not call the sister process "SCL" (for
"scheme community library").  Or, if one wants a noun (easier to
illustrate) and to reflect that a package can be made up from more
than library, "SCPR" for "scheme community package request".  After
all, you can not only surf on the waves but can also have fun driving
a boat on the sea.