Implicit phasing on imports

[per-gron]

As in http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.1568

In practise this would mean to drop syntax-begin and/or import-for-syntax, and just have import, letting the module system infer in which phases you want to import each module. I think this would make it more intuitive to write macros, which is a good thing.

[per-gron]

Hmm.. I've forgotten most of what's required to implement this.

Trying to remember:

• Currently, the system has no ability to import things for macros, because I removed the syntax-begin form.
• The module metadata "compiletime-dependencies" and "runtime-dependencies" are what we want to have in the end, but we want to calculate them not directly from the import statements and which phases imports were made, but by looking at the identifiers in the macroexpanded source code.
• I'm not sure about how loading, visiting and invoking should be done while macroexpanding though?

[per-gron]

Doing this might remove the need of storing phase numbers in some parts of the environment ns data structure, (but not all?) in particular the table thing.

[per-gron]

One thing that needs to be done is to modify resolve-imports so that it only returns one value (not a list of module references). To do this, module-import needs to be modified so that it doesn't load the modules immediately, and the default *external-reference-access-hook* needs to be modified to load modules when they are encountered. Furthermore, something needs to be done about macros, I think, because *external-reference-access-hook* doesn't get invoked for macros.

BUT: I'm not sure this should be done at all. What I've done so far might be sufficient, because it might actually be desirable for modules to be loaded eagerly in the REPL. But how does that work together with phases? I don't know.

[per-gron]

For the record: The module metadata fields compiletime-dependencies and runtime-dependencies are now calculated from the expanded source and not from the import expressions.