just like any other constraint from the definition.
In particular, if the schema validity depends on an outer context,
the constraints should be solve in that outer context, not here.
Fixes#314
We may want to do this more often, but it may have a performance penalty.
Anyway, we need this check here, because previously the code was assuming
that the goals are known to be consistent, and we are just wanting to
default them, which should never make them inconsistent, just more instantiated.
The current solution is a bit of a stop-gap, until we redo the defaulting
story, and separate it form improvement.
This largely reverts 54831eace2 and takes
a different approach. This way path names are normalized before feeding
them to the parser, rather than when comparing the module to be loaded
with the module already loaded. This works better because it takes into
account the current directory at the time when `loadModuleByPath` is
called.
Since multiple modules may import the same module, the module loading
process keeps track of whether a given module has been loaded already.
To do this, it looks up the module by name and, if found, compares the
paths of the two modules to check that they come from the same file.
However, these paths are not guaranteed to be normalized, so it can
sometimes print an error message when attempting to load the same module
from a file named in two different ways. This commit normalizes the file
paths before comparing them. Alternatively, it may make sense to enforce
an invariant throughout that module file paths are normalized, though
this may require care to avoid overly verbose messages.
Recent changes resolved issue 002, so we no longer need to indicate that
it's expected to fail. Other small changes to the type checker have
made things like type variable numbers change slightly.
