* Limitations:
Does not work in combination parameterized modules, as I am
about to redo how that works.
* General refeactorings:
* Namespaces:
- We have an explicit type for namespaces, see `Cryptol.Util.Ident`
- Display environments should now be aware of the namespace of the
name being displayed.
* Renamer:
- Factor out the renamer monad and error type into separate modules
- All name resultion is done through a single function `resolveName`
- The renamer now computes the dependencies between declarations,
orders things in dependency order, and checks for bad recursion.
* Typechecker: Redo checking of declarations (both top-level and local).
Previously we used a sort of CPS to add things in scope. Now we use
a state monad and add things to the state. We assume that the renamer
has been run, which means that declarations are ordered in dependency
order, and things have unique name, so we don't need to worry about
scoping too much.
* Change specific to nested modules:
- We have a new namespace for module names
- The interface file of a module contains the interfaces for nested modules
- Most of the changes related to nested modules in the renamer are
in `ModuleSystem.NamingEnv` and `ModuleSystem.Rename`
- There is some trickiness when resolving module names when importing
submodules (seed `processOpen` and `openLoop`)
- There are some changes to the representation of modules in the typechecked
syntax, in particular:
- During type-checking we "flatten" nested module declarations into
a single big declaration. Hopefully, this means that passes after
the type checker don't need to worry about nested modules
- There is a new field containing the interfaces of the nested modules,
this is needed so that when we import the module we know we have the
nested structure
- Declarations in functor/parameterzied modules do not appear in the
flattened list of declarations. Instead thouse modules are collected
in a separate field, and the plan is that they would be used from
there when we implmenet functor instantiation.
use that information to emit error messages rather than warnings.
This provides more specific messages than simply allowing the
affected type variables to remain uninstantiated and failing later.
It also causes some examples that otherwise would have ambiguous
types to fail earlier. This converts some test instances where
REPL defaulting would eventually succeed into examples that fail
outright instead. I largely think these instances are improvements.
Fix up the test suite. This mostly delays defaulting
warnings into "showing specific instance of polymorpic
type warnings", but requires actual fixes in a small number
of places. Those places were higly questionable, in my opinion.
This changes the way the special "Error" type is used. The error
message now contains only an explanation of what happened,
and the actual malformed type is the parameter of the error function,
which is always used at kind `k -> k` where `k` is the malformed kind.
This fixes (or at least improves) #768
Currently we only use this for the Prelude, which is baked into Cryptol.
Previously we used to save it in a temporary file, which would show
up in error messages, leading to bad user experience and unreliable
test outputs.
Also improves the shadowing errors.
Fixes#569
The name "demote" is only meaningful to those who already know what
the Cryptol primitive does. Also, due to recent changes in the error
and warning messages, the name "demote" is showing up much more often
in REPL output. For example:
Defaulting type argument 'rep' of 'demote' to [2]
Showing a specific instance of polymorphic result:
* Using 'Integer' for type argument 'rep' of 'Cryptol::demote'
These messages will hopefully be made less confusing to non-experts
if the name "demote" is replaced with "number".
This does a bunch of small changes, that should improve the usability
of Cryptol. Namely:
* When we are forced to make up a name, pick something derived from
the source of the variable, annotated with the unique.
* When pretty printing a schema, use "n,m,i,j,k" for numeric variables
and "a,b,c,d,e" for value type vairable.
* When generalizing, put numeric vairables first.
The main user visible effect of this might be that sometime things on
the Cryptol command line are instantiated in a slightly different way:
we get `inf` sometimes when we got a finite example before.
We could work around this if it is an issue, but I am not sure which
behavior is more reasonable.
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.
This change partially reverts changeset c620cbf2, which fixed#296,
which was about supporting `:t (~)` in the REPL.
As of this change, `:t (~)` will no longer work in the REPL.
The regression test for issue #296 is removed.
