Implicitly loaded modules in the future?

[patrick-kidger]

@PetrKryslUCSD

It seems to me that requiring users to care about files is counterproductive. If a user needs some functionality, it should be in a package, and no include is needed. Developer is free to organize things into files, based on the DAG representation of the code (in the developer’s head), but why would a macro be needed for that? Just decide on what should the physical representation into files should look like a then use import . In my mind files and modules are independent concepts. I could have organized my package as a single giant file, but the modules would work just as well as when I keep it one module per file.

This approach doesn’t scale as well. An include()/package-based approach is:

• Heavyweight, requiring the creation of a package at every branch point in the code dependency DAG. That’s a lot of overhead just for some helper file.
• Requires a developer to look up O(n) code in the size of the codebase n to track the dependencies of any individual piece of code. This is as opposed to just O(log n) in a well-designed file-based approach.
• Implicit. Within each package, dependency DAGs are held only in developer’s heads, instead of being explicitly written down. Harder to on-board people / easier to make mistakes.
• open to spooky-action-at-a-distance. It is possible for construct natural examples in which changes in one set of files will affect method resolution in unrelated parts of the code.