> On Oct 23, 2022, at 10:35 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> 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.
>

Why the “lib” part which seems redundant?

>> 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?

The spec would probably say “it is an error” to have both.

>
>>> 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.
>

The library design process should not be centralized (“centralized” in the sense of having a single body of experts saying what is good and bad).  Good design should be determined by the community using the libraries once they are implemented.  There needs to be a place for competing designs so that the best ones can emerge after some experience using them.  For this approach to become a reality there is a need for a common distribution format for libraries so that they can be experimented with by any Scheme user in any compatible Scheme system.

What should be centralized is a list of known libraries so that users can find these libraries more easily than a google/github/… search.  The scheme.org site is aiming to centralize all things Scheme so it would make sense to have the list of libraries there.  It even has a git server (gitea.scheme.org) where authors could put their libraries if needed to publish their code if for some reason they prefer not to use github or gitlab.

>>
>>>
>>> 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.

Please do not use email addresses for identification in source code because this will be an open invitation for spammers that scan Scheme source code.  Moreover, there’s a growing consensus (in programming languages in general) that “@“ is used in library names to indicate versions, so it should be reserved for that purpose if ever used.

I would suggest this format for “hosted” libraries:

   (<internet-host>/<rest> <other-part>...)

Where <internet-host> would have to contain a period and <rest> is anything valid in a symbol.  So the combination of at least one “.” and at least one following “/” would indicate a hosted library.  For example (github.com/feeley/roman demo) .

By the way this library name syntax is currently supported by try.scheme.org if you want to try it out.  For example you can type at the REPL:

    (import (github.com/gambit/hello demo))

and the interpreter will fetch the library directly from that github repository.  Read the tutorial on try.scheme.org to know more about how to write and use hosted libraries.

>
> 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)).
>

One important advantage of the syntax I propose is that it puts in the code the URL that can be used to visit the library’s repository.  Many tools (code editors, mail readers, etc) will detect URLs and create a hyperlink for them.  For example, in this email I see “github.com/gambit/hello” highlighted with a hyperlink.

>> 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 agree that the URL part will typically designate a repository which can contain more than one library.  That’s why the other parts of the library name are used to pinpoint which library is to be imported if there is more than one in the repository.

> 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.

What if you want automation to avoid fiddling with configuration files and installers?  Please read the following paper to see a context where this is useful:

   An R7RS Compatible Module System for Termite Scheme (ELS 2020): https://www.iro.umontreal.ca/~feeley/papers/HamelFeeleyELS20.pdf

Marc