jckarter/clay — pull request #409 by jckarter (2012-10-12 23:38:48+00:00)
Title: Fix #272 by changing dotted import behavior

- Eliminate ModuleHolders and use Module objects to represent module values directly
- Change the behavior of field ref expressions as follows:
- If the field reference form textually matches a qualified module name imported in the current module, evaluate to that module. For example:

import foo.bar;
foo_bar() = foo.bar;

- Otherwise, evaluate the left-hand expression and proceed as before:
- If the left-hand expression evaluates to a module value, look up the right-hand identifier in the module and evaluate to the found object
- Otherwise, evalue the expression as `__operators__.fieldRef(left, "right")`
- Explicitly disallow `public import foo.bar;` without an alias. This didn't really work anyway, and doesn't make sense with the new implementation.

Dotted module names must be handled textually, because a module "foo.bar" is not an actual member of the module "foo". In order to properly support modules as first-class values, the former "module holder" implementation cannot work, because it is impossible to have equivalent static objects with different sets of members: Either different module holders representing the same module would be unequal, or submodules would have to be considered members of the parent module, which violates the current modularity and location independence of modules. This seems like the best way to me to support qualified module names and module values together. There is the weird behavior that a qualified name still works even if the root component is shadowed by a local name, but other than that, I think this usually does what you mean.

Fixes #272.