Thanks for the detailed response. Comments inline,

On Fri, Apr 29, 2016 at 2:23 AM, Faré <fahree@gmail.com> wrote:

On Thu, Apr 28, 2016 at 8:05 PM, Ian Tegebo <ian.tegebo@gmail.com> wrote:
> I've been reading the manual, papers, and slides on ASDF and XCVB. As a
> frame of reference, I prefer the qualities exhibited by Racket's
> implementation of modules. I was disappointed both to see XCVB bitrot, and
> then to see that a major ASDF overhaul would be necessary.
>
[...]
As to me, if I had to design a build system today... see
http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/

I've booked travel to the Land of the Houyhnhnms , but have yet to depart.

> That said, ignoring Racket/ASDF/XCVB, I'm curious about how loading multiple
> versions of the same system could possibly be implemented in Common Lisp
> (CL). [...]
>
What is your use case? Do you want a fully automated general answer,
or just a manual hack that works for one or a few very specific
systems on a specific implementation? In the former case, you're
facing an uphill battle. In the latter case, many hacks can help you.

The former is intriguing, the latter's useful. Curiosity about a general solution is what prompted this thread, but I'm happy to learn of workarounds.

Various hacks:

[...]
* detecting packages present before and after loading the system
itself, so you can rename them away.
* using my system package-renaming to cleverly rename relevant
packages around the compilation, loading and/or use of one system.
* fixing your systems to not refer to packages by name at run-time,
and if possible not at load-time either (or make sure to wrapper
load-time in proper package-renaming).

With respect to package renaming, I've asked Michał Herda to comment on whatever issues he'd had with "destructive package renaming" [1]. I understand it as referring to the state-based global-reader implementation of packages, which seems to entail well known problems like reentrancy and readtable leakage.

Would you correct me or otherwise expand on the matter? I.e. I'm trying to understand the tradeoffs between package renaming methods. My use cases are:

a) package local nicknames for readability

b) implementing a variant of Racket's "#lang"

c) supporting multiple versions of a dependency

I know that some implementations directly support a), and that both a) and b) may be implemented with ASDF, but I didn't know about c).

> On the JVM, there's the notion of "classloader" that can be used to load
> multiple versions of the same class. Unfortunately, the only approach I can
> imagine is to use some form of package renaming.

If what you want is a general way to have multiple versions of any
system in a same image, you're out of luck, and/or [...]

Yes, I'm primarily interested in a general way: thanks for entertaining the discussion.

If what you want is a build system that is full-featured like XCVB
with plenty of dependencies yet compiles things in-image like ASDF [...]

Or then again,
you could use the XCVB farmer model, where the build image with lots
of dependencies farms the compilation to workers that only need to
load a small stub, and no package renaming is necessary.

This approach sounds like one motivated by version conflict between the build system and system being built. Is that correct?

I wasn't really thinking about that, but now that I am I'm reminded of various parts of your paper [2]. The bootstrapping, upgrading, and distribution of ASDF seems very thorny indeed.

[1]: https://github.com/phoe-krk/pseudonyms/issues/2#issuecomment-215534567

[2]: http://fare.tunes.org/files/asdf3/asdf3-2014.html

Ian Tegebo