Aliases

[Alex Buckley]

I personally think aliases should have versions. The "implementation"
version of a physical module declaration could be in different universe
than the "exported interface" version of an alias provided therein.

But I have some dumber questions first:

On 9/10/2012 1:16 AM, Paul Sandoz wrote:
> In the following example:
>
> module x at 1 { requires optional a@<3; }
> module y at 1 { requires a at 3; }
> module b at 1 { alias a at 3; }
> module b at 2 { alias a at 2; }
> module b at 3 { alias a at 1; }
>
> where x at 1 and y at 1 are the roots, resolution should fail since only
> one version of b is allowed in the in the resolved set of modules,
> *even though* y has an optional dependence of a at 3 [*].

If there was no such thing as an alias, and instead physical modules 
a at 1/2/3 were available, would resolution still fail? I know you have 
been experimenting with resolution of optional dependencies, but I am 
surprised that "requires optional a@<3" stops resolution - alias or not.

> In the following example:
>
> module x at 1 { requires a@<3; }
> module y at 1 { requires a at 3; }
> module b at 1 { alias a at 1; }
> module c at 1 { alias a at 2; }
> module d at 1 { alias a at 3; }
>
> where x at 1 and y at 1 are the roots, the resolved set of modules could be
> either:
>
> [x at 1, b at 1, y at 1, d at 1] or [x at 1, c at 1, y at 1, d at 1]

It is very surprising to see both x at 1 and y at 1 in a resolved set, since 
they have mutually incompatible dependencies. Could I declare a module 
m at 1 that requires x at 1 and y at 1, and then resolve with m at 1 as the root? 
Surely not. I have a feeling the use of multiple roots indicates 
compile-time, and each "resolved set" is really a set of two sets (one 
per root).

BTW I like your rule for monotonic alias versioning. (Slightly better 
formalized as: "Given modules X at i and X at j, where i<=j, any alias 
provided by X at i must have a version less than or equal to an alias of 
the same name, if any, provided by X at j.")

Alex