Carl Mäsak

> The symbol that gets installed is an object, but let's give it the object type `Module`. Its properties correspond to the variables defined in the topmost scope at the...

Aye; coming back to this issue, it now seems clear that each imported module needs to have as a type its own anonymous `Module` subtype. The pattern here is a...

I think I've arrived at a good design that covers all the bases. First of, we're going to make the keyword `import`, not `use`, for a number of small reasons....

Ok, so. First off, in this design, exports are explicit. I would do it through an `is export` trait, which will later evolve to an `@export` annotation. If people want...

Immediate afterthought: since `import m;` is a short form of the third form `import m from "m";`, I think it makes sense to always allow the final string (occurring in...

I initially meant to include a fourth form in the design: import from "m"; import from m; Note that this form is the only one that contains nothing between the...

Oh, and for a brief while before I rejected the fourth form, I made up the rule that forms 1..3 would *require* there to be at least one export from...

One more thought for now: let's call the thing I realized in [this comment](https://github.com/masak/007/issues/53#issuecomment-151866662) "early module binding". Early module binding is necessary with the first form of import: we need...

Leaving circularity aside, it's perfectly admissible for the same modules to be imported several times during the same _compilation_ process, as we traverse the compunits and the import relations between...

Does it make sense to compile _but not run_ a module that's imported? I'm asking because I just realized that something like if False { @export sub foo() { }...