Anyone interested in "package versioning"?

[Faré]

Dear Robert,

you seem to be complaining about issues inherent in any shared
namespace, where names can clash. There is no "solution" to that.
That's a *whole point* of a namespace that names may be bound to
different values, and that incompatible values *shall* clash. Not a
bug, a feature!

One could imagine that with real first-class namespaces, it should be
easier to implement dynamic binding of such names, static binding in
lexical scopes, virtualization, etc. Thus, within a same image you
could have several binding-sets, and though every binding-set contains
compatible bindings, different binding-sets could be mutually
incompatible without problem (as long as you don't try to have data
from one binding-set interoperate with incompatible code from
another). Happily or unhappily, CL has no such provision in its
package system.

If you want to develop some kind of "better module system" on top of
CL, good luck with that: you will have to not only create something
that is indeed technically better, but you thereafter have to convince
other people to use it so you may benefit from it — and you'll
probably have to start creating a massive body of work using your
system before people even look at it. I fear the global side-effectful
nature of CL will make it very hard to keep anything clean on top of
CL, but I'm looking forward to what you have to offer.

Personally, I'll say that lisp-interface-library (aka lil) was started
as a demo of how you could write more modular code in CL. By modular,
here, I mean that you can define interfaces and multiple
implementations of those interfaces, what more with parametric
polymorphism as well as ad hoc polymorphism. While I think of lil as a
technical success, I certainly failed to produce a massive amount of
software using it, and have therefore not gotten many people
interested in extending it (though I have a handful of contributors).
Such interfaces offer a solution to the problem of allowing the
peaceful coexistence of multiple instances of solutions to an existing
problem. They of course cannot solve the issue of these multiple
solutions claiming the same name; if you want multiple versions of an
interface implementation, they need different names, though you're
welcome to use some version as part of the names.

PS: If you have concrete ideas on how to improve ASDF and/or
Quicklisp, there are more specialized mailing-lists and/or bug
tracking systems for that. For instance, you may propose some kind of
off-the-side version tracking and version incompatibility tracking to
ASDF, to express constraints that you can't retroactively include in
the systems themselves.

PPS: You might be interested in reading my blog post about build
systems, especially
the part discussing programming in the large.
    http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
As for poverty, no one need be ashamed to admit it: the real shame is
in not taking practical measures to escape from it.
    — Perikles, speaking about the poverty of CL regarding modularity solutions