Mercerenies / tfactor

0 stars 0 forks source link

Top-Level "Module" #8

Open Mercerenies opened 4 years ago

Mercerenies commented 4 years ago

There's lots of awkwardness with the top-level "module", namely that it isn't actually a module. It's a collection of names that occasionally behaves like a module, just often enough to be deceptive.

In particular, the top-level is never actually module-loaded, which means module synonyms and functor instantiations at the top level just... fail silently. How do we deal with this?

I see two options.

  1. We actually turn the top-level into a module. Make it a resource with its own RId, tweak lookupFn and co to work with an empty identifier, and give it a module-load phase and module-load dependencies. (Note that, under the current system of nested modules, every module in existence would implicitly depend on the top-level, meaning it actually couldn't instantiate functors or use module synonyms. This is still better than silent failure, though)
  2. We make it so that the user never deals with the top-level. Give every file a module. This is basically what we were going to encourage anyway, but we just make it mandatory. It becomes physically impossible for anyone other than the VM to define names at the top-level, and the VM only does so for certain special primitives (of which there are none right now, but may as well keep that door open) and for modules defined for files, Primitives, or Prelude. Then the awkward pseudo-module behavior, while still present, becomes much less noticeable and possibly even irrelevant.