On 18 May 2016, at 13:57, Alessio Stalla <alessiostalla@gmail.com> wrote:

Can you elaborate on that?

The stance on packages found in the mentioned Quora post is based on the old misconception about packages being modules, or "software packages" in the Linux distribution sense. They're not. They are really just namespaces, containers of symbols. So it does not make any sense, to me, that they have versions. Software has versions, not names.

However there are places where having in thw same image multiple versions of the "same" component may be useful.

Eg. an application that wants to load older versions of file formats or database structures.

There is also the case of library components, when you want or need to load different components depending on different versions in the same image. A depends on B and C. B depends on L version 1, C depends on L version 2.

Would being able to deal with such situations be better than the current situation where basically Xach ensures that all the libraries published in quicklisp can compile on sbcl using the same version of all components?

I think it *is* already possible, even if no convenient machinery for it exists, to load the same symbols under different packages (i.e. to use different names for different versions of the same concepts).

(defpackage p ...)
(load (compile-file "p-1.0.lisp"))
(rename-package "P" "P-1.0")
(defpackage p ...)
(load (compile-file "p-1.1.lisp"))
(rename-package "P" "P" "P-1.1")

p-*.lisp start with (in-package :p)

Then you can compile code against p (latest version), p-1.0 and/or p-1.1.
Of course each p-*.lisp must be "nice" - only define things in package p.

Or conversely the original name of the package could contain a major version number (then I'd advocate against providing a versionless nickname, given that a change of major indicates a change of API).

On 18 May 2016 at 11:36, Stelian Ionescu <sionescu@cddr.org> wrote:
On Wed, 2016-05-18 at 00:21 -0400, Jean-Claude Beaudoin wrote:
> Hi CL Pros,
>
> I just came across a post on Quora
> <https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common-Lisp-fi

Don't worry too much about this article, it falls into the "Social Problem Of Lisp" category. Useless.

> x-the-world/answer/Robert-Smith-9?srid=dnzK>
> by
> Robert Smith where he mentions the idea of assigning some sort of
> "version"
> to Common Lisp packages in order to improve code configuration
> control.
>
> This seems to me to be a pretty neat and interesting idea!
>
> Has anyone of you explored such a concept, or know of anyone that
> did?
> Or, is anyone of you curious about it?

It's a very bad idea to do code versioning in the linker/loader in
order to load two versions at the same time. Saying it makes code-reuse
hard is preposterous.

While unix systems can select amongst different versions of libraries at link time, they don't allow linking with different versions at the same time by the same component. An application would have to do it explicitely with dlopen/dlsym.

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

__Pascal Bourguignon__