macrotypefunctors / typed-module-lang

Prototype language with simple types, modules and functors
0 stars 0 forks source link

Nested modules and 'with' #2

Closed iitalics closed 6 years ago

iitalics commented 6 years ago

I have been reading A Modular Module System more closely and it looks like implementing nested modules and withs would be both a more comfortable solution to many module problems, and would very likely be easier to typecheck than module-level let bindings.

The paper gets away with using a single environment because it essentially treats the body of a sig as an environment. For what do environments represent? They track which types are opaque and which are aliases, and they track the signatures of any modules in scope. This is exactly the same information that a sig contains.

Thus when we are matching signatures, we extend the current environment with the body of the more specific sig (left hand side), and this operation is dead simple as its just a hash-union with the body of the sig. When we are matching functors, we extend the environment by adding a named submodule for the functor arguments. Again we choose the more specific signature but this time its from the right hand side (because of contravariance).

AlexKnauth commented 6 years ago

Okay. Currently we have the m-env and the normal env. The m-env contains the modules and the normal env contains the type declarations. You think these should be merged into a single environment that contains modules, type declarations, and val declarations, and that signatures should be able to contain submodules because (a signature should be able to contain everything that one of these environments can)?

iitalics commented 6 years ago

Yes, precisely.

AlexKnauth commented 6 years ago

I agree with you on merging the environments into one, but not that we should allow signatures to contain submodules. (at least for now)

iitalics commented 6 years ago

OK