Modules, pros, cons

[umuro]

here are different kinds of Modules on different languages.

• Ruby: Module is an actual class that can be messaged like other classes. Hence, programs can change module at Runtime. The cost is that no one will come up with easy type checking for that language. Goes against static type checking.
• Haskell, OCaml. Modules are only in the source code. Functions are resolved to function ids for runtime.
• Rescript. Modules are mapped to Javascript Objects. In the name of Javascript readability. However, there is a module calculus and it operates during type checking phase. So it resolves modules before runtime just like other strongly typed langages and yet maps them to Javascript objects.
• Elixir. Like Haskell, OCaml but one is able to write module processing functions that will operate before runtime.

So the languages have 3 approaches

• Modules are just namespaces that are resolved before type checking
• Modules are a domain with their functions. Module dsl operates along with type checking.
• There is a class for modules it is part of the runtime. To the extent that it makes type checking impossible.

What is the matter? By making, modules part of the runtime, one is able to disable static type checking totally because type checking depends on modules.

Currently I started modules as runtime objects. But it might easily disable future type checking, by having this or that feature.

Modules resolved before runtime
Pros:

• Everything becomes simpler. There is no specifics of defining a module function vs global function. Math.pi, Math.add are just names. Imports are resolved before runtime and more efficiently.
• There is no way to disable type checking.
  Cons:
• There are no module objects around. They have to be constructed separately for debugging info.

In the name of simplicity, I am tending to preresolving modules with a cost of implementing a separate module info export.
Processing modules at run-time is bringing the risk of making static type checking impossible.

Summary:
I decided to demolish existing Modules. And parser will just delegate Math.sth as a single identifier for the existing mega switch statement. The reason for that is we are about to demolish any possibility of static type checking by allowing modules to be modified during runtime.

Steps:

• I will proceed to change the parser. Math.pi, Math.add will resolve to Math.pi, Math.add. The parser will keep identifiers with modules as one identifier.
• This will allow current switch statements operate with module names. Less complication.
• Later, a very lightweight module preprocessor will process import, include, export statements.
• There will be a separate info API for debugger to get module related info as there won't be any modules in bindings.

[umuro]

Steps.

• I will proceed to change the parser. Math.pi, Math.add will resolve to Math.pi, Math.add. The parser will keep identifiers with modules as one identifier.
• This will allow current switch statements operate with module names. Less complication.
• Later, a very lightweight module preprocessor will process import, include, export statements.
• There will be a separate info API for debugger to get module related info as there won't be any modules in bindings.

[OAGr]

This seems reasonable to me. As long as we can still do things like, Math.add, and with functions inserted (like, List.map(fn)), we should be fine for the next few weeks or so.

Thanks for listing out all the choices!

I'll think about the greater question some more. It's tricky stuff.

[umuro]

Having Ruby like modules is a big mess. Introducing a lot of types and processing to runtime. Experimenting with runtime modules costed me almost 2 weeks. Module name resolution and exports will be part of multi-pass compilation. Clean and no runtime changes.
Also it will be easier to provide detailed information with multi-pass compilation

• pass 0 external includes.
• pass 1 modules. Dumps module members. Behavior imports will be part of first pass.
• pass 2 types. Dumps function types and errs on type failures.
• pass 3 call optimization. Most of the time, there is no need to switch on types at run time. After type resolution functions can be directly called.
• pass 4 documentation. Add embedded documentation to comments.
• pass 5 final executable.
• At this point there is a dictionary of modules with typed functions. We can call this compiled debugger runtime information. It will be hanging on the project for lookup.