Proper modules migration plan

[dhil]

This is a meta-issue to track the progress of upstreaming the new module system.

My intention is that the current and new system should live side-by-side for a while to avoid inadvertently breaking (correct) code that works today. The reasoning is that the new module system should be an improvement, not a regression. But there may be bugs lurking in there. Initially the new module system will be an opt-in option (in other words, disabled by default). After a couple of "stable" releases, I envisage removing the old module system and enable the new one by default.

I have spent some time getting an overview of the implementation of the new module system. Since it is a rather big and invasive change, I would like to upstream it in batches as outlined below.

Phase 0

• [x] Introduce the syntax and semantics of import (Patches #599 and #602).
• [x] Patch up the current module system (Patch #602 and #609).
• [x] Switch examples to use import rather than open at the top-level (Patch #607).

Phase 1

• [ ] Introduce the notion of compilation units.
• [ ] Introduce a flag for toggling between loaders, e.g. --legacy-loader (defaults to on).
• [ ] Upstream an alternative loader (currently exists in a separate branch) .

Phase 2

• [ ] Consolidate qualified and unqualified names internally.
• [ ] Update typing environment to work with qualified names.
• [ ] Introduce a flag for toggling between module systems, e.g. --legacy-modules (defaults to on).
• [ ] Type check modules.
• [ ] Compile modules away during the sugar-to-ir pass.

The timescale, that I have in mind, spans a couple of weeks. I would like to resolve this issue by ~~June 6~~ ultimo July. Meaning that the new module system would effectively be upstreamed by the beginning of June.

Closing this issue should involve transitively closing #337.

[dhil]

I am obviously lagging behind my own plan; I will try to land the loader next week.

[jamescheney]

Snoozing until post-0.9.0