Am So., 23. Okt. 2022 um 15:47 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:
>
>
> > On Oct 23, 2022, at 4:34 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >
> > 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.
>
> Are you talking about the layout for SRFI sample implementations or more generally any library?  The layout "srfi-${N}/lib/srfi/${N}.sld” seems to be specific to SRFIs.

I was using SRFIs as a particular example.  In general, the layout I
propose would be
"repository/lib/library-name-part1/.../library-name-partN.sld".  Only
library definitions must reside under the "lib/" path.

> I’m interested in specifying a general layout that works for any library, i.e. (import (A B C)).  Also I’m interested in a layout for “publishing” libraries so that they can be accessed by a “library installer” (a vague term that means some procedure for using a library in a Scheme system… possibly a simple “cp -R X Y” for some Scheme systems and a “awesome-scheme-install X” for other systems).  So the layout is not prescribing how compatible Scheme systems store the libraries on the filesystem (that’s the Scheme implementation’s business).
>
> The main aspects that must be addressed are how the .sld file is named and where it is located in terms of directory structure.  This is the basic information needed by a “library installer”.  I see two alternatives:
>
> 1)  A/B/C.sld
> 2)  A/B/C/C.sld
>
> The first works well for small libraries that don’t need any (or few) auxiliary files.  The second allows grouping files related to library (A B C) in the directory A/B/C, for example included files like A/B/C/C-impl.scm, implementation specific files like A/B/C/C.chibi.scm, configuration files needed by the library, sublibraries, etc.
>
> Given that they are both useful, the library layout spec should support both layouts.  Note that this naturally works for sublibraries, for example the .sld file for library (A B C D) could be in either of these places, regardless of where the C.sld file is located:
>
>   A/B/C/D.sld
>   A/B/C/D/D.sld
>
> That is all I’m proposing at this point because locating the .sld file is the critical first step for installing a library.
>
> I would be OK with only specifying the second layout (A/B/C is a directory), but I fear that this would be cumbersome for small libraries so programmers would gripe.

In the case of the second option, "A/B/C/C.sld", would a file
"A/B/C.sld" be ignored?

> > 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.
>
> A process for publishing portable libraries is OK, as long as it is not the only process for publishing libraries.  The location where a library comes from should be decided by the programmer using the library, not a self-selected group of people running a central repository (regardless of how good their intentions are).  In these days of the web revolution it should be clear that decentralization is the way to go.  But for this to work there’s a need for a standard publishing layout like the one I propose.

Agreed.  I don't propose this sister project to SRFIs as the only
place or process for publishing libraries.  It is intended to be just
one of the many decentralized places.  But it is intended to be a
well-known one with an active community and with some rules (based on
the experience with SRFIs) to have a certain level of quality, also
when it comes to documentation.

>
> >
> > 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.
> >
>
> This would require a centralized process to assign the author/organization names.  Moreover it is a barrier for (shy) newcomers that must fill out a form for having a name assigned to them.  Then there’s a need for a policy for name registration when there are conflicting names or people who “park” names… I’d love to get the “mf” name for “Marc Feeley” to be able to do (import (from mf …)) but I’m pretty sure Matthew Flatt and Matthias Felleisen would like it for them too.
>
> Thanks to the web, there’s already a globally unique name that has been assigned to every programmer (or one that is easy to get), the URL of their github/gitlab/… account.  So what I propose instead is that this name be used to identify the author or organization, and instead of (import (from github.com/<account> …)) I propose the shorter (import (github.com/<account> …)) which should be unambiguous given that the use of “/” is valid but “inadvisable” in R7RS.

The advantage of this would be that the SRFI-sister organization would
only have to maintain a short registry, namely that of valid prefixes.
This list would contain "github.com/' or "gitlab.com". Or every name
with a "/" in it (for web addresses) and a "@" (for email addresses)
would be reserved.

Alternatively, one can think of what a non-normative appendix of R6RS
proposes, namely a Java-style naming: (import (org gambitscheme
compiler)). Or (import (com github mnieper)).

> Using the author’s account URL can also serve as a place to store the library’s source code so that tools can easily download the source code, for example:
>
>    awesome-scheme-install github.com/feeley/bonjour
>
> to install the library (github.com/feeley bonjour) .
>
> So the name assignment and decentralization issues can be solved together.

I am not so convinced that the library name and the repository address
are or should be in one-to-one correspondence.  It is a *package* (not
formally defined (yet?)) that is stored in a repository.  A package
can consist of more than one library.

I would leave the question how to resolve a package location from a
library name to the awesome-scheme-install program, which can use some
configuration file.