Spec - module system

[haxscramper]

• [ ] Importing exported symbol
• [ ] Importing non-exported symbol
• [ ] export
• [ ] include
• [ ] Magic value interpolation for include strings (it supports "$home" and maybe couple other patterns on top of that)
• [ ] Ambiguous call resolution
• [ ] import A/[X, Y, Z]
• [ ] import except
• [ ] from A import B
• [ ] import A as B
• [ ] Explicitly specifying module names when importing
• [ ] import A as nil
• [ ] Execution order of the toplevel statements in modules
• [ ] Order of semantic checking of the modules, visibility of auto-generated entries (related to macros, but probably should be specified as a part of the module specification).
• [ ] what happens when module is imported twice
• [ ] what happens if the module imported twice while having different environment (for example var state {.compiletime.} in when check)
• [ ] {.define(flag).} before the module import

[saem]

Can we mark push and pop as in the danger zone of being axed or heavily changed? I think they're really problematic implementation wise and the syntax doesn't get enough information to know what to do and when.

Perhaps taking a step back, where should we note this info so we can cross reference it with stuff in the spec? My feeling is it should be in the spec as it's rapidly becoming the source of truth, but you might have a better idea.

[haxscramper]

Can we mark push and pop as in the danger zone of being axed or heavily changed? I think they're really problematic implementation wise and the syntax doesn't get enough information to know what to do and when.

Perhaps taking a step back, where should we note this info so we can cross reference it with stuff in the spec? My feeling is it should be in the spec as it's rapidly becoming the source of truth, but you might have a better idea.

Spec - remove, redesign or make non-experimental/issues/55