"Part of the new evolvability design is the notion that we need better control over interface versions, so that different modules can for instance have requirements on other modules, and if two modules require the same module but happen to require different versions of that module, those can both coexist. Unless of course those two modules require some kind of exclusive access to a resource that cannot be shared. They’ll have to negotiate then.

When I say, “Use module::dog” I get Fido version 1 and when he says “Use module::dog” he gets Fido version 2. But in either case a lexically scoped alias of dog means this in my particular case. And beyond that, perhaps we can even provide mechanisms so that modules themselves can be polymorphic with respect to their own version numbers. So you can say, “Yes, I know I’m pulling in version 2 but I know that you know how to emulate version 1. And I have to stick with version 1. Or maybe that’s implicit: you say: “ I want version 1, you might get version 1 or you might get version 2 emulating version 1”. So we allow modules to then mutate their interface and their set of semantics over time, and yet have a way to identify a certain set of semantics that can be locked in. for corporate security.

This is actually something I learned from of the Wall Street companies that use Perl. When they pull in modules they tend to say: “I want this version of the module”. They always put version numbers, and they never remove those versions. And then if they have a conflict they have to negotiate that by hand right now. We’re trying to give them a way of negotiating that automatically."