On 30/07/2025 22:07, vqn wrote:
Over the past few months, I have been working on an implementation of the ML Basis system for Poly/ML. It supports the complete mlb spec and is available both as a library and a cli tool:
This looks great! Thanks for making this available. I have various comments which I'll report via Github.
On a side note, I have been trying to implement incremental compilation by caching compiled .mlb files (i.e compiler namespaces) and exporting and reimporting them through {save,load}ModuleBasic. I have however been running into the issue that exporting each .mlb to a different on-disk module causes opaque types mismatch when reimporting them. What would be the reason for that?
I have managed to work around it by exporting everything to the same file, but that result in a fairly large cache, e.g ~45mb for smlfmt (1.2mb executable, 15k loc). I suppose the reason for that is that I export the basis library as well, but I'm not sure there is a solution for that.
I am interested in incremental compilation as this could allow Poly/ML to be used on a large project which already has MLB files for another compiler, so I would like to see whether I can help get this working.
I have found SML/NJ's CM to be effective at avoiding recompilation. This is not surprising as it is the result of considerable research - see the references in the CM User Manual (https://smlnj.org/doc/CM/new.pdf). This makes a difference in practice: for example, adding a new function to a utilities module on which every other module depends does not cause everything to be rebuilt. Although I have not used MLKit, it appears that its incremental compilation of MLB files would behave similarly, according to the documentation (https://elsman.com/mlkit/mlbasisfiles.html#managing-compilation-and-recompil...). Out of interest, did you consider implementing cut-off incremental recompilation for MLB files, in particular as described in Elsman's paper (https://elsman.com/pdf/sepcomp_tr.pdf)?
Phil