Libraries at scheme.org?
Lassi Kortela
(26 Jan 2021 22:49 UTC)
|
Re: Libraries at scheme.org?
Vladimir Nikishkin
(27 Jan 2021 01:28 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 07:28 UTC)
|
Re: Libraries at scheme.org?
Vladimir Nikishkin
(27 Jan 2021 01:34 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 07:46 UTC)
|
Re: Libraries at scheme.org?
Arvydas Silanskas
(27 Jan 2021 08:26 UTC)
|
Re: Libraries at scheme.org?
Marc Nieper-Wißkirchen
(27 Jan 2021 08:36 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 08:51 UTC)
|
Re: Libraries at scheme.org?
Arvydas Silanskas
(27 Jan 2021 10:34 UTC)
|
Re: Libraries at scheme.org?
Marc Feeley
(27 Jan 2021 13:17 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 14:07 UTC)
|
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 16:28 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 17:34 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 18:10 UTC)
|
Re: Libraries at scheme.org?
Marc Feeley
(27 Jan 2021 19:54 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(29 Jan 2021 13:28 UTC)
|
Re: Libraries at scheme.org?
Lassi Kortela
(27 Jan 2021 08:37 UTC)
|
Re: Libraries at scheme.org?
Duy Nguyen
(28 Jan 2021 10:29 UTC)
|
> On Jan 27, 2021, at 9:07 AM, Lassi Kortela <xxxxxx@lassi.io> wrote: > >> One way to achieve this is with a syntax for module/libraries that includes an (optional) version number, combined with the ability to create aliases. So if B says >> (import (C)) >> you could >> (define-module-alias (C) (C @v1.0.1)) >> in a global configuration file to force the import in B to use v1.0.1 of C. > > Good idea. > > Are you interesting in standardizing the format of such a configuration file? I think we should, and been thinking about it on and off for about a year. The snow-fort.org package.scm files are a reasonable starting point. Chicken egg files contain somewhat similar information. > > The library name (C @v1.0.1) is almost equivalent to the R6RS-style library name (C (1 0 1)) or (C (v1.0.1)). > > IMHO the optimum solution would be to: > > - extend the R7RS rules to permit a list as the last library name part to give the version number > > - extend the R6RS rules to permit non-negative exact integers as library name parts; and to permit symbols in addition to integers in the version number part > Yes I’m interested in standardizing the format of the configuration file and also the syntax for version information. I point interested people to our paper explaining the rationnale for certain choices in Gambit’s module system (https://doi.org/10.5281/zenodo.3742443). Two things are particularly relevant here 1) R6RS puts the version number in the “library” form. This is not ideal because managing version numbers manually is error prone. It is better to leave the “tagging” of the sources with the version information to the VCS. 2) R6RS uses semantic versionning for checking the compatibility of libraries (what is required vs. what is available). Semantic versionning is a neat theoretical approach that just doesn’t work in practice (because humans are the ones that are responsible for ensuring the semantic version attached to a library is “correct”… and humans are error prone). So I think R7RS should not adopt the R6RS syntax or semantics for the version information. Gambit uses a symbol starting with an “@” to indicate the version, for example (import (foo bar @1.2.3)) . Gambit also uses git for the VCS, and for this to work well the “root” is considered to be a package and there can be libraries inside that package. So libraries (foo bar) and (foo baz) are two libraries inside the package foo. There could be a toplevel library (foo) in package foo, but it is not a requirement. Simple libraries typically are the only library at the root of the package of the same name. Finally, it is packages that are versionned and not libraries. This matches most VCS systems, including git, that put version information on the repository (package) and not on individual files. Marc