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

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.

[...]

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

[...]

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

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?

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

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

Understood! :)

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

There can be a default configuration file.

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

I am going to read the paper soon. Thanks for the link.

> Marc

Ditto