SRFI sample implementation repository layout Marc Feeley (15 Oct 2022 11:19 UTC)
Re: SRFI sample implementation repository layout John Cowan (15 Oct 2022 15:00 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (15 Oct 2022 15:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (15 Oct 2022 16:16 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (15 Oct 2022 22:18 UTC)
Re: SRFI sample implementation repository layout Daphne Preston-Kendal (16 Oct 2022 07:10 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (16 Oct 2022 08:34 UTC)
Re: SRFI sample implementation repository layout John Cowan (24 Oct 2022 19:00 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (24 Oct 2022 20:25 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (24 Oct 2022 21:17 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (24 Oct 2022 21:14 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (16 Oct 2022 04:52 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (16 Oct 2022 05:05 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (16 Oct 2022 08:57 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (16 Oct 2022 12:08 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (18 Oct 2022 21:23 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (19 Oct 2022 14:53 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 15:33 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (19 Oct 2022 18:21 UTC)
Re: SRFI sample implementation repository layout Göran Weinholt (19 Oct 2022 19:35 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (19 Oct 2022 21:50 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 22:11 UTC)
Re: SRFI sample implementation repository layout Göran Weinholt (26 Oct 2022 08:44 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 21:12 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (22 Oct 2022 22:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (19 Oct 2022 21:37 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (22 Oct 2022 22:54 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (23 Oct 2022 08:34 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (23 Oct 2022 13:47 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (23 Oct 2022 14:35 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 12:17 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 15:24 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 17:26 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 18:10 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 18:37 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (25 Oct 2022 19:50 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 20:18 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (25 Oct 2022 19:22 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 20:57 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 09:03 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 15:30 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (26 Oct 2022 15:33 UTC)
Re: SRFI sample implementation repository layout Jakub T. Jankiewicz (26 Oct 2022 16:03 UTC)
Re: SRFI sample implementation repository layout Per Bothner (26 Oct 2022 16:18 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:02 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (26 Oct 2022 16:11 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 16:34 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:37 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (29 Oct 2022 11:12 UTC)

Re: SRFI sample implementation repository layout Marc Feeley 25 Oct 2022 17:26 UTC

> On Oct 25, 2022, at 11:23 AM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> On Tue, Oct 25, 2022 at 5:16 AM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>
> 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.
>
> That's a great feature.

I’m glad you like it!  While I can understand the automatic downloading is not to everyone’s taste, it is very convenient for sharing code as it reduces the barrier to collaboration by avoiding the tedium of locating and installing the library after the other collaborator has made a change.  But the main point here is not the automatic dowloading but rather the combination of having a unique name for the library, knowing the location where it can be downloaded, and the absence of centralized control (for registering new libraries, user names, etc).

> I would rather see the URI enclosed in double quotes, which would eliminate concerns about conflicts between Scheme identifier syntax and URI syntax. It would only be slightly more verbose to say (import ((uri "https://github.com/gambit/hello") demo)), but would be even clearer.
>

To me the terseness and elegance of the notation is important so the choice between these two is clear to my eye:

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

  (import ((uri "https://github.com/gambit/hello") demo))

Moreover, currently the first notation is allowed by R7RS for a library name, but not the second, so nothing would have to change in R7RS. We just need a convention for the community to adopt. For example you can use (github.com/gambit/hello demo) as a library name in Chibi Scheme and it will look for the file github.com/gambit/hello/demo.sld in the module search directories. This means that an independent installer could be written for Chibi to dowload the sources and put them in one of the module search directories (without having to change Chibi). This is probably a few lines of shell script calling wget/tar/etc. In principle that notation should be supported by other R7RS conformant systems although the presence of a “/” in the name may trigger bugs in the implementation (the R7RS says it is “inadvisable” but not “an error” to use “/” in a library name).

Note that I’m not proposing that a full URI be used because a URI has a bunch of unnecessary information, such as the https:// part, that is not normally relevant (I rarely if ever enter it at the browser’s address bar).  Undelimited Scheme symbols cover almost all the characters acceptable in a URI (assuming the part after the URI path is empty which would be the case here).  The characters | and \ are not allowed in the relevant parts of URIs, and I believe special characters like ()’,; are valid, so for URIs with those characters a delimited Scheme symbol could be used.

Note that this approach to naming libraries is also used by GoLang, so there’s something to be said about its practicality.  See https://encore.dev/guide/go.mod

Marc