> 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. 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. > 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. >>> 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. > > [...] > >> 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! . > > 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. > >>>> 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 Marc
