What to do with 2+ modules at UNIT level

The -use- command in Perl (6) indicates which file must be loaded, without there being a guarantee that there is actually anything with that name inside it.

This is fine.

However, now that we have the capability (in spec) of having multiple versions of a module (class / package / grammar / etc). residing in memory at the same time, and imports are lexical, so we will be doing "use Foo" far more often than before, we need to look deeper at what "use Module" actually means.

Assume we have a file AAAAA.pm that contains:

module AAAAA { sub a is export { say "a" } } module BBBBB { sub b is export { say "b" } }

This file is loaded into memory with:

use A:name;

After that the 2 modules exist at the same UNIT level: one under the synonym of "A", and the other with its longname "BBBBB". And all subs (from both modules) marked "is export" are imported. So currently you can not alias another top level module in a -use- statement.

If sometime later in another lexical scope the code say:

import BBBBB;

would Perl 6 need to be able to import from that module, even though in that scope it had not been loaded with "use"?

Alternately, would:

import AAAAA;

work as well, even though the "use" was aliassing the module to "A"? And if that would be possible, shouldn't we allow the full From/Auth/Version selection process on "import" as well?

I guess the whole problem comes from modules specifying their LFAV (longname, from, auth, version) in the module statement, whereas the selection on which version of a module to load, is done at the file (UNIT) level.

One way to solve this, would be to disallow more than one module (class, etc) at the UNIT level. Please note that this would not affect modules embedded in other modules, as these are not visible from the outside anyway, even though they can add to the export list of the outer module. Then we would be sure that the constraint in "use" would be correctly applied to the right module.

We will find other situations, in which the discrepancy between a file and a module in memory, may cause problems. Enforcing having only one module at UNIT level in a file, would make things simpler.

Would be nice if we could discuss and resolve this at YAPC::NA as well!

Raku / old-design-docs

What to do with 2+ modules at UNIT level #46