On 10/09/2025 23:44, Phil Clayton wrote:
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. There is no mechanism to load dependencies automatically.
The attached example works even though, in t1.sml, saveModule is immediately followed by loadModule for the module just saved _without_ restarting a new session. Can we avoid restarting the session generally, like this? (This would certainly simplify matters.)
Yes, using loadModule immediately after saveModule should work because it replaces the entries in the name look-up tables with references to the loaded module.
Also, I have noticed something odd. The attached example can be run with
poly < t1.sml poly < t2.sml
However, if the system call to "sleep 1" is removed from t1.sml, the second command using t2.sml produces the error:
Exception- Fail "Segment already exists" raised
Is there a race condition somewhere?
I haven't tried your specific example but I'm fairly certain that this has to do with the way that module identifiers are currently generated. Each module has to have a different identifier so that if a module depends on others all the dependencies can be sorted out. Currently this just uses a time-stamp and so if two modules are generated in quick enough succession they could have the same time-stamp. Although this has been used for saved states for a long time it isn't the best way to do it and won't work if someone wants reproducible builds. It would be better to create a hash of the contents and use that.
There are a few things like this that will need to be sorted out before this code is ready for wider use. At this stage I really want to be sure that this general scheme will meet the needs of the MLB code.
David