Aliases

[Paul Sandoz]

Hi,

Aliases, unlike views, currently have version numbers that can be independent of the version of the module itself.

In the following example:

module x at 1 {
  requires a;
}

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 is the root, what should the resolved set of modules be for compilation (select the lowest version of a module in the range)?

  [x at 1, b at 3] or [x at 1, b at 1]

It all depends on whether the module versions of b or the alias version of a are selected.


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 [*]. 


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]

Which one to select is arbitrary unless the version range of a is taken into account in which case the solution is:

  [x at 1, b at 1, y at 1, d at 1]


So... this would seem to indicate versions ranges of aliases should be taken into account even though only one version of an actual module can be present in a resolved set of modules.

But... it would also seem to indicate that version ranges of aliases add additional complexity in terms of understanding the result of resolution.


Thoughts?

Paul.

[*] Arguably the linking stage could be smart enough not to link x at 1 to a at 3, that works statically but not for dynamic interactions.