On 13/09/2025 18:20, vqn wrote:
I've been testing the new dependent modules branch and managed to get saving / loading modules working correctly with opaque types.
There are, at least at the moment, some restrictions. saveModule creates a new module but this is not recorded in the exporting process. So exporting two modules from the same Poly/ML session will not work as you might expect. The answer is to call saveModule as the last action in a session. Then start a new session, load the module just saved along with any others, add some more declarations and create a new, dependent, module. The dependencies must be loaded explicitly before a dependent module can be loaded.
That is unfortunately not applicable here, but reloading the module instead of restarting into a new session seems to work.
There is no mechanism to load dependencies automatically.
From what you've said I think this should be sufficient for MLB. I would assume that the implementation can keep track of the dependencies.
Dependencies are already tracked, so loading them before a dependent module is fairly simple.
I have however ran into a single problem, which is that a new module seems to depend on all previously loaded modules, even if nothing seems to be shared. Attempting to load a module fails with "Mismatch for existing memory space". Attached is an example in which two modules, each containing a single value, are exported sequentially. Trying to load the second one without the first fails.
As I understand it, an MLB file is compiled in its own, initially empty, namespace. Only the modules for MLB dependencies would be loaded, so the saved module for the MLB file would depend only on the modules of its dependencies. Is the issue that loadModule/saveModule are tracking module dependencies independently of namespaces?
Interestingly, it works fine if the modules are exported from different threads.
For me this still failed but possibly there are race conditions here.
Phil