>     dearth of actively developed applications
>
> Part of the reason for the dearth is the lack of good libraries!  That's
> the whole point of R7RS-large: to provide a language suitable for
> mainstream application development.

And it's an admirable target. Big libraries are sorely needed.

> (We will miss that target in a
> number of ways, no doubt.)   The reason I have focused on prior art both
> inside and outside Scheme is precisely to incorporate what people have
> been found to need.

I greatly enjoy working with you because you're one of the few
programmers who actively catalog prior art and not just in your own
community. The ignorance of prior art has been one of the main forces
stalling software for decades and it's disheartening that so much good
work ends up in the round file
(https://www.urbandictionary.com/define.php?term=round%20file).
Cataloging of previous efforts should be an integral part of all our
activities.

> Sets, for example, have never been present in any
> Lisp that I know of; people have always thought hash tables good
> enough.  But in Python they were added as a language feature after a
> while, because they are common and you don't think of using a tool if
> you don't have it right there in the list.

Clojure now has sets too. Having them in the language helps a lot.

> That is not my intent; new libraries can be (scheme ...) but revisions
> will need some other way to mark them.  Per contra, nobody has *ever*
> suggested yearly revisions!  Personally, I think that's insanely
> aggressive; people want to use the latest, but not if it changes too
> quickly.

As usual, the yearly-revisions system is for me a part of a broader
vision. Such a language should be developed such that there is a core
group of people (that would be us) dogfooding the language
(https://en.wikipedia.org/wiki/Eating_your_own_dog_food).

The Scheme and Lisp spirit has traditionally been "I don't like that
invention; I'll go use my own alternative". The group members should all
force themselves to use each other's inventions for daily work. That's
the way to iron out any problems in it and arrive at a cohesive structure.

I thought of starting a project like this for Scheme last year, but it
would take too much energy for me. If I could somehow manage to convince
a bunch of Common Lisp or *ML (SML/OCaml) people to join, I would stick
with it and put up with any setbacks. Collaboration on that scale would
just be too cool to pass up.

The various Lisp/ML communities are brimming with talent and together we
could do all of the following in a few years:

- Fully structural/visual programming environment supporting all of
these languages, with skinnable syntax, visual macros, saving code to
backward-compatible text files.

- A massive set of practical libraries -- the same libraries for all of
these languages, not arbitrary differences from language to language --
with shims so that the libraries are idiomatic to use in each language.

- One high-performance virtual machine supporting all of these languages
as first-class citizens, not Language A as a leaky macro wrapper on top
of Language B.

- Interop between dynamic typing (Lisp/Scheme) and static (ML) worlds.

- A huge stack of featureful FFI bindings to popular C libraries.

- Great documentation and websites.

- Easy community-hopping and job-hopping between these languages.

Because we are all tinkering in our own corners, we aren't on track to
do that. The technical problems are surmountable; the social ones may
require a genius.