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