One reason why it is actually not a good idea to have library names
like (github.com/gambit/examples hello) just occurred to me:

If, at some point, an author decides to move their repositories from,
say, GitHub to GitLab or Codeberg, or Savannah (which can be due to
political reasons or because some repository provider ceases to
exist), the names of this author's libraries would no longer reflect
where they can be found.  While this would not harm the functionality
of the libraries, it would confuse users (who like to click on the
auto-formatted links in their editors) and loaders that pull source
code directly from the internet.  Of course, the libraries could be
renamed, but this should only become necessary if a new version of the
library becomes gravely incompatible with the previous version.

Making a library name dependent on a location thus clashes with its
primary use of giving a (universal) name to a particular library.  In
other words, it makes sense to base a library name on a URN, but not
on a URI.

A URN-like scheme (the SRFI process is one) at least solves the
problem with namespacing.  What's missing is a connection between URN
and URI, which should not be part of the library definition by the
above reasoning.  It belongs to some metadata outside of the library;
this necessary metadata can also contain some solutions for security
issues.

Am Mi., 26. Okt. 2022 um 11:03 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> Am Di., 25. Okt. 2022 um 22:57 Uhr schrieb Marc Feeley - feeley at
> iro.umontreal.ca (via srfi-discuss list)
> <xxxxxx@srfi.schemers.org>:
> >
> > > On Oct 25, 2022, at 3:22 PM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> > >
> > > Am Di., 25. Okt. 2022 um 14:17 Uhr schrieb Marc Feeley - feeley at
> > > iro.umontreal.ca (via srfi-discuss list)
> > > <xxxxxx@srfi.schemers.org>:
> > >
> > > [...]
> > >
> > >>> 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?
> > >
> > > Assume the following layout for a repo
> > >
> > > README.org
> > > /mnieper/foo.sld
> > > /documentation/foo.tex
> > > /documentation/example.sld
> > >
> > > If the repo's top-level directory were the search path, a Scheme
> > > system's loader could also pick up the library definition in the
> > > documentation directory, although it has not been meant to be part of
> > > the package (and may even generate an error when loaded because it
> > > contains just demonstration code being referred to by the TeX
> > > documentation).
> > >
> > > On the other hand, with a distinguished subdirectory that must only
> > > contain library definitions that are part of the package, the problem
> > > is solved cleanly in universally:
> > >
> > > README.org
> > > /lib/mnieper/foo.sld
> > > /documentation/foo.tex
> > > /documentation/example.sld
> > >
> >
> > I think you have a valid concern. On the other hand there are already some repositories for libraries (from various Scheme implementations) that don’t have the “lib” part, so they would not be directly accessible if “lib” is a requirement. Also, some repositories do use “lib” but not at the top of the repository.
>
> When we standardize a repository format for Scheme packages (which
> doesn't exist yet), we should get it right and not neglect corner
> cases. This may mean that existing repositories will have to be
> restructured (or have to add an explicit manifest file) to conform to
> the standardized format, but this has to be done only once. I don't
> think we should prefer one layout over the other only because this
> initial work may be less for one group (but maybe more for a different
> group).
>
> >
> > Another point of view for the above layout is to say that it is possible to refer to the library (documentation example), and if it is garbage (an example of a library that has a syntax error), then you simply should’nt be importing it.
> >
> > Are you thinking of automated library management tools that scan the filesystem and find all the .sld files in the tree? To solve this issue the manifest file you talk about below might be required to mark /documentation/example.sld as a non-library .sld file.
>
> Automated library management tools are one example, but also a Scheme
> implementation itself that, say, wants to precompile everything that's
> there.  I agree with what you say below, namely that the layout/file
> naming should be standardized, making a manifest file, in most cases,
> unnecessary.  Having a dedicated lib/ folder removes the need in many
> cases.  It also helps to quickly see what the actual Scheme code is
> and what libraries are offered just by looking at the directory
> structure.
>
> > > That said, I wonder whether a manifest file (containing Scheme datums)
> > > should be standardized instead.  This is more flexible (and would be
> > > easy to write an manifest file generator), which may be needed when
> > > not only library definitions but also other resource files make up a
> > > package.
> > >
> > > [...]
> > >
> >
> > I think that eventually a manifest file will be required for complex scenarios.  However, I would like the layout to not require a manifest so that there are minimal things to put in place to publish simple “portable” libraries.  If I have a simple library with a single .sld file I don’t want to have to create a manifest that contains basically no additional information, or that has to be trivially updated whenever a new commit is done (such as a timestamp or version identifier).  Also, manifest files open up a big can of worms and it will be hard to achieve a consensus.  It will be good to gain experience before writing the spec for the manifest file, but perhaps early on we can reserve a few locations in the library layout to put the manifest.
>
> I agree (and see above).
>
> Let me also add that, for complex packages, something more than
> `cond-expand` may be necessary and that configuration of the package
> (happening before installation) may require some code to run.  It has
> to be evaluated whether this has to be reflected in a manifest
> file/directory structure and how.
>
> At the moment, we often see tests like (cond-expand (gambit ...)
> (chibi ...)), but this is not very future-proof. In these tests, it is
> unclear what exact feature is supposed to be tested against, and it is
> unclear whether this feature is stable in future versions of the
> respective Scheme implementation.  This is a lesson we can learn from
> Autoconf (another lesson we learn from it is that
> M4+Shell+Perl+Makefile+... can lead to a codebase that is hard to
> maintain, but this is an entirely different matter).
>
> > >>> 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.
> > >
> > > Ok.
> > >
> > > [...]
> > >
> > >>> 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.
> > >
> > > People seem to like the SRFI system also because it is a well-known
> > > address, it attracts people with very different backgrounds, leading
> > > to lively discussions, which help shape proposals.  Building a second
> > > library repository under its roof would be just an offer to the Scheme
> > > community.  It does not and should not preclude other places from
> > > developing and publishing libraries.
> > >
> >
> > I fear that a sister process will dilute the manpower.
>
> I think it will only work if it is mainly parallel to the SRFI process
> by precisely the reason you give.  The simplest implementation of such
> a sister process would be just to maintain (under the roof of the SRFI
> process) a second list besides SRFIs.  When an author submits
> something, they decide whether they want to submit it as, say, SRFI
> 238 because they think what they propose should be an integral of
> future Scheme systems or as, say, SCPR 38, because it is mainly a
> portable (random) library.  It would be expected that, eventually, the
> SCPR numbers would be much higher than the SRFI numbers.
>
> Of course, this discussion is orthogonal to your suggestions about a
> standardized package format.  The "SCPR" proposal will also only work
> if more people than just Daphne and I feel that some distinction
> should be made between various proposals that, at the moment, all end
> up on the SRFI list. It will only work if the SRFI editor, Arthur, is
> convinced about the proposal and willing to maintain a second list of
> "SCPR"s using the same infrastructure.  The formal requirements for a
> "SCPR" may be higher, e.g. the repository may have to be of a standard
> format (as we are discussing here), and the implementation may have to
> be portable (and efficient without any extra tweaks necessary).
>
> > >
> > > [...]
> > >
> > >> 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 didn't think of spammers.
> > >
> > >> 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.
> > >
> > > This looks neat. But how is security handled? Scheme code can wipe my
> > > hard drive. If my Scheme system loads and executes code automatically
> > > from the internet, I think I should feel frightened.
> >
> > Definitely there needs to be security guards for this to work! In Gambit (and try.scheme.org) there is a whitelist of trusted repositories and libraries are only automatically dowloaded from those repositories. By default only github.com/gambit is trusted, but a user can reset or extend the trusted repositories from the command line or with calls to module-whitelist-add! .
>
> You will not only have to trust the maintainer of the
> github.com/gambit repository (which is probably okay unless, say,
> Marc's computer is hacked), but you will also have to trust the
> service behind github.com.
>
> So, maybe we want to make the naming system flexible enough to cover
> use cases where trust is needed.  For example,
>
> (github.com/gambit/hello demo)
>
> would be an (unsafe) shortcut of
>
> (github.com/gambit/xxxxxx@xxx demo)
>
> where xxx is Git's hash (or another standardized hash derived from the
> file contents).
>
> > > Another question is which hosting protocol should be supported and
> > > which authority decides about it.  Or will this be a question of each
> > > Scheme implementation, so that some will support automatic downloading
> > > from some addresses while others need their awesome installer?
> >
> > The automatic downloading should not be a requirement and it is not trivial to implement, so it should not be expected to be a widespread feature (unless it really catches on an becomes a “must have” feature!). In any case, the programmer should have a way to disable automatic downloading even if the system supports it.
> >
> > A standard library publishing layout that is based on a network accessible VCS (such as git) will greatly simplify library installers. In fact, if the layout is simple, a short shell script might suffice for many Scheme systems. For Gambit the library installer once supported all three of git, mercurial and subversion but only git has seen serious use because it has such a high popularity among programmers.
> >
> > >
> > >>> 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.
> > >
> > > At least in Emacs, you can tell the editor/mailer/... to parse
> > > sequences of Scheme symbols similarly.
> > >
> > > I find a sequence of symbols more Scheme-like but I see this point of you.
> >
> > OK… if it helps, we still write call-with-current-continuation and not (call with current continuation) and not ((#\c #\a #\l #\l) (#\w #\i #\t #\h) …).  So lists of things are not always the natural thing to use.
>
> As I said, I don't have a strong opinion against putting (com github
> gambit) into one symbol (and see the advantages of that).  But I think
> that the naming of "call/cc" is a different matter.  It is a name that
> is meant to be opaque for the computer; the name parts only matter to
> us humans. On the other hand, the three parts of github.com/gambit can
> be given some meaning relevant to a computer.  That said, I don't
> think we need to delve into this discussion except for we still need
> to persuade Arthur about using a symbol.
>
> Marc