15

This thread is dedicated to projects dreamed, designed, implemented and maintained by our community (per this chat discussion). By project, we mean code that is more than a few lines and/or is under extensive development so a thread in Mathematica.SE is not a suitable format to publish it (though it is ok if the project has its own specific thread - don't forget to include the link then). Collaboratively developed packages for example.

Instructions

  • Please post only those projects that you are related to (you are the author/contributor/maintainer)
  • Only post projects that (in whatever state) are publicly available and the repository where it is stored can be viewed/accessed by users.

  • Each answer should introduce a single project, and should contain the followings:

    • a short description of the project: status (alpha, beta, ...), what it does, what can one expect if s/he downloads it, dependencies, possible hazards, etc.
    • if the project is already in the implementation stage, a link to the site where code is maintained (other SE.thread, github, etc.)
    • one or a few images that demonstrate what the project can do (not necessary)
    • the authors, developers and maintainters of the project
11

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .