-
Notifications
You must be signed in to change notification settings - Fork 123
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* 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.
- Loading branch information
Showing
72 changed files
with
2,644 additions
and
1,641 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.