Am Fr., 11. Sept. 2020 um 16:31 Uhr schrieb <xxxxxx@ancell-ent.com>:

> > [...] The unfortunate thing with Scheme is the dearth of actively
> > developed applications. Apps are needed to put library designs to
> > the test.
>
> This is actually a very, *very* bad sign about the state of the Scheme
> world.  One I'm planning on addressing at least a bit, but Real Life
> is hitting me very hard for the foreseeable future.

We have probably more implementations of Scheme than applications
written in Scheme. :) But even with so many implementations, the
competition with other languages is hard because there is usually more
money to maintain high-quality implementations of those languages.
(Another reason why it was very costly to the RNRS process to, well,
alienate Chez and Racket.)

> > [ library versioning ]
> >
> > At all times, we would make sure that code using different years'
> > editions can easily be mixed. I.e. we would take care not repeat the
> > Python 2 vs Python 3 incompatibility mistake.
> >
> > As for the specific naming, I guess (import (scheme char)) could be
> > (import (scheme char 2020)). R6RS comes standard with a library
> > versioning system, but it seems it hasn't gotten much traction.
>
> Something I expressed a desire for in my R6RS no vote was being able
> to load different versions of a library into one address space.  Not
> at all sure how or if this could be done sanely, for example I'm not
> sure how to take your above scheme and turn it into easy to use name

I see that different library versions in the same application make
sense when you pull in modules from different vendors. But there is a
serious problem I am not sure whether and if how it can be solved.
Look at the following scenario:

The library (fantastic bar) defines the bar record type together with
some convenience procedures.

The library (space) offers some procedures on bar objects and needs,
for its implementation, a rather modern version of (fantastic bar), so
it makes the version more specific when doing (import (fantastic bar
((>= 2025)))).

The library (time) offers some other procedures on bar objects and
needs, for its implementation, some method that was later dropped in
(fantastic bar), so it does (import (fantastic bar ((<= 1949)))).

The main program now looks like:

(import (only (space) (make-space-bar))
           (only (time) (age-bar)))

(age-bar (make-space-bar))

Now, this program cannot work because we have to versions of the
record type coming from the two disjoint loadings of the library
(fantastic bar).