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 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 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 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 Göran Weinholt 26 Oct 2022 08:41 UTC

On Wed, Oct 19, 2022 at 06:11:26PM -0400, Marc Feeley wrote:
>
> > On Oct 19, 2022, at 5:49 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
> >
> > On Wed, Oct 19, 2022 at 12:35 PM Göran Weinholt <xxxxxx@weinholt.se> wrote:
> >
> > That is a misconception about Akku. R6RS and R7RS libraries are
> > self-describing, so Akku does not require any particular repository
> > layout. You just need to use any of the common file extensions: .scm,
> > .sls, .sld, and so on. You can run "akku scan" in a repository to verify
> > what libraries it finds. Most packages that are published to akkuscm.org
> > actually come from git repositories that were not prepared whatsoever
> > for Akku.
> >

> > Even if Akku can work around it, Marc's making the point that not
> > having to make a separate choice for every single SRFI is
> > beneficial itself, and that we should therefore adopt a
> > convention.

I'm not arguing against having a convention, but I disagree that Akku
would be working around the convention. I'm saying that for whatever
convention you come up with: good luck, and Akku will support it.

> Akku is a neat piece of software!  However I view the “akku scan”
> operation as a “hack” even if it works well in practice.  There’s
> nothing to say that each .sld file is really a library (some .sld
> files may be WIP that don’t work, or sample files used by a
> “tutorial” library, or a data file (a SLiDe format?)).  If it also
> searches for .scm, .ss, etc then that opens the door to more
> false-positives… maybe those files are actually included in some
> main .sld file, so they aren’t really libraries per-se.

You would be hard pressed to find any widely deployed software that
does not utilize a hack. But I disagree with the statement that Akku's
scanner is a hack.

The first pass where Akku looks for .sld, .scm, .ss files is a filter
to find files that might contain source code. Maybe some files should
be ignored and you can then add them to .akkuignore.

The next step is to parse those files with a (forgiving) Scheme reader
to see if they have a library or define-library form. This step also
supports Guile and Chez modules to some extent. The important parts of
this process are to find the library/module name and included source
files. This data is processed into "artifacts".

It doesn't matter where in the repository an artifact resides. Some
people put source under an src/ directory, some do it so that (foo bar
baz) becomes /foo/bar/baz.sls, others don't include the first part
because it's already in the name of the repository, so if you check
out the foo repository you might find that (foo bar baz) is in the
bar/baz.sls file. And there is no standard library->filename mapping
so sometimes people use the mapping that happens to work with the
Scheme they used.

Anyway, at this point there is a list of artifacts that represent
libraries, bare source files for include, etc. The next major step is
to "install" the artifacts into the .akku/lib directory. In general,
an artifact will need to be installed at multiple locations using
symlinks. Different Schemes have different library->filename mappings,
and Akku implements all of them. Suppose you have these artifacts:
(λ), (example) and (series :1). Akku's installer will print warnings
that the first name is not supported by Sagittarius, Mosh and
IronScheme. The installer will then create these files:

.akku/lib
├── akku
│   └── metadata.sls
├── %ce%bb
│   └── main.sls -> ../λ.sls
├── %ce%bb.sls -> λ.sls
├── example
│   └── main.sls -> ../example.sls
├── example.sls -> ../../src/example.sls
├── series
│   ├── :1.sls -> ../../../series-1.sls
│   ├── 1.sls -> :1.sls
│   └── %3a1.sls -> :1.sls
└── λ.sls -> ../../lambda.sls

There are more complicated situations than this that Akku also solves,
e.g. installing <name>.chezscheme.sls files in those cases where
(e.g.) Chez Scheme needs its own variant of a library, or expanding
R7RS cond-expand at the define-library level into multiple R6RS
library forms.

But as you can see, the :1 component has become :1.sls, 1.sls and
%3a1.sls to support different library->filename mappings that are in
use today. There have been attempts to standardize this mapping before
(as a SRFI) but Akku's approach is a pragmatic response to the fact
that this hasn't happened yet.

A major motivation/insight behind Akku is that storing source code in
files is an historical accident. There is no need (at least in Scheme)
to be so closely tied to where in the file system library files are
stored. All that matters is that you can install a package and then
import its libraries. What matters is the name in the
library/define-library form and that you can have another file that
imports the library by using that name. Whatever is in-between those
steps is just some glue that needs to be solved somehow. The code
could even be stored in some database, it doesn't have to be a file
system.

There are several complicating factors in implementing all this, but I
don't think there is any need to go into too much detail. One part
that I would consider a hack is that R6RS includes are implemented by
recognizing several widely deployed macros that implement include, but
that this is done without using a macro expander. It's a matter of
implementation effort. And I think the only other hacky part would be
that Akku knows a little too much about the implementations it
supports: cond-expand features, built-in SRFIs, library->filename
mapping, etc. These can change over time and it might be better for
Akku if implementations had a way to report this data.

Btw, there was a design for a package manager for Go that used the
same basic design that Akku uses. To me it seemed poised to become the
de facto Go package manager, but then the official Go module system
was announced and it was something very different. I say, as someone
who has used Go professionally for many years, that its current module
system is an disaster.

> P.S. Nevertheless, please consider adding Gambit support to akku!

It was a few years since I looked at Gambit but it didn't seem to have
a library/module system with self-identifying source files. So I'm not
sure what Gambit support in Akku would mean. But if you now have R7RS
support then I should have a look again.

/Göran