> On Jan 27, 2021, at 5:34 AM, Arvydas Silanskas <xxxxxx@gmail.com> wrote:
>
> Indeed, R6RS does. Admittedly I was more so thinking about R7RS when writing that message, sorry for confusion. I agree manager shouldn't be adding layer of version if it already exists,
> but what if it doesn't? Would a semi-formal convention to name libraries in R7RS with a version as last name-part be enough? Consider chain A (enduser app) depends on B (some framework), which in turn depends on C (utility library).
> As an A author I want to have possibility of control over the C version, particularly so if need be, I can use a newer C version than what B depends on in the case of api-nonbreaking bug fixes. If B imports its C import with `(import (C v1))`,
> it's not entirely clear to me in what way library manager would trick B to actually use (C v1.0.1) instead.

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.

This is implemented in Gambit's R7RS compatible module system.  See section 4.3 of our ELS2020 paper for details (https://zenodo.org/record/3742443#.YBFnDS_b2CM).

Marc