Fine-grained module system for Mathematica / WL
Description
The aim of this project is to provide a much finer-grained module system for Mathematica development, than the one which uses packages. The motivation for this is that in many cases, an even small snippet of Mathematica code can represent a complete and useful bit of functionality. Making it a package / assigning a context name / etc often is too much of a mental overhead. Even more importantly, combining smaller chunks for code into packages often makes it problematic to reuse these pieces elsewhere in the same project, and generally makes code refactoring in Mathematica much harder than it should be. The proposed system aims at addressing these and some other problems.
Some intended features
Here is a list of features planned for this system
Convention over configuration
This design philosophy is well-known to save a lot of effort for a developer, when certain things are done in more or less the same way most of the time. What is meant here is that all aspects of project-management should be as simple as possible, tailored to the specifics of Mathematica language and programming practices.
Drop-in code
The idea is that if you have a chunk of code, you can just drop the file into the project and start using it right away in other places in the project. The dependency-resolution should be as simple as possible. For example, if you dropped the file into some folder, the code in the other files in this folder should be able to use symbols you export from the dropped-in file, without explicit imports.
Single - symbol imports
It should be possible to import single symbols, similarly to e.g. Python:
from package import somefunction
This is not currently possible with the standard package-based system.
Automatic / maximally simplified namespace management.
The developer should not really think what the namespace for a given chunk of code / file should be - the system has to do it. Here is the currently used approach:
By default namespaces / contexts are assigned based on where a given file is, relative to the top-level project folder, in a hierarchical manner. If needed, one should be able to over-ride that. So, the developer just writes code, but does not normally insert any statements like BeginPackage, EndPackage, Begin and End.
By default, a single exported symbol is the one which is the name of the file. If it should be different, or one needs to export more than one symbol from a file, this can be done.
Interoperability with the standard package - based module system
One should be able to write hybrid code, where parts are written in a standard way, while other parts use this module system. One should also be able to compile the project written via this module system into a standard package, for deployment / release purposes.
Running several versions of the project at the same time
The new system will allow one to run several versions of the same project simultaneously, without conflicts, since they will live in different namespaces / contexts. This is not possible for the standard packaged-based module system, while quite useful to have in practice.
Current status
The project is in the very early stages. There is no package version of it yet, but there is a fully-working prototype which implements some of the mentioned above features - see the zipped folder with the code notebook and two sample projects (actually, versions of the same single project), structured using this module system
Github repository: FineGrainedModules
The package version / manual / etc to come soon.
